Shorewall users - Mar 2004 - qualys.com reports packet fragmentation vulnerability

Hello,

I am not subscribed to the list, so please cc me on any replies!  My
organization subscribes to a security advisory service that outsources
remote penetration testing to qualys.com.  Our servers were recently
scanned by qualys for the first time.  A host (running shorewall) acting
as a firewall/gateway for an internal network was reported to be
vulnerable to a packet fragmentation vulnerability which supposedly
allows the destination tcp port of a given packet to be overwritten.  I
have not had any success learning more about this alleged
vulnerability.  Our web server, also running shorewall, was _not_
reported to be vulnerable.  I am quoting the technical description of
the vulnerability from qualys.com below.  Is this vulnerability common
to all iptables firewalls like shorewall, or is there some element in my
setup which has introduced it, or is the vulnerability identification
from qualys bogus?  Thanks for any assistance you can offer!

The host is running redhat 9, kernel 2.4.20-28.9, iptables-1.2.7a-2.

shorewall version:
1.4.6c

ip addr show:
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:ba:d6:4b:81 brd ff:ff:ff:ff:ff:ff
    inet 192.1.2.110/24 brd 192.1.2.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:ba:d7:6b:d3 brd ff:ff:ff:ff:ff:ff
    inet 66.167.152.178/29 brd 66.167.152.183 scope global eth1

ip route show:
66.167.152.176/29 dev eth1  scope link
192.1.2.0/24 dev eth0  scope link
169.254.0.0/16 dev eth1  scope link
127.0.0.0/8 dev lo  scope link
default via 66.167.152.177 dev eth1

Here are the vulnerability details from qualys; I have no other details
about their exact methods:

Host Vulnerable to Packet Fragmentation (QID:34010)
Assume that the firewall is dropping TCP SYN packets sent to a
destination port of 25 but accepts TCP SYN packets sent to port 80.
i.e., if we send a TCP SYN packet to the destination port 25, we will
receive no reply. But if we send a TCP SYN packet to port 80, we get a
SYNACK reply packet.

Now we break up the TCP SYN packet to port 25 into IP fragments. We do
this in a few ways. The simplest way is a straightforward breakup. A
more complicated way is a breakup with overlaps. If we receive an RST or
a SYNACK reply to this SYN packet, fragmented in one way or the other,
the firewall is vulnerable.

Fragmentation with overlap means that the fragment offset is set such
that the data in one fragment is overwritten by the data in another
fragment. A typical fragmentation test involves breaking a TCP SYN
packet into three fragments: Fragment #1 consists of the IP header and
12 bytes of IP payload (i.e., 12 bytes of TCP header), which has the
destination port equal to 80. Fragment #2 consists of the IP header and
8 bytes of IP payload, which overwrites the destination port in Fragment
#1 with a new destination port 25. The third fragment completes the TCP
header. With a vulnerable firewall, we would receive a SYNACK reply or a
RESET reply, depending on how fragments are reassembled by the target
host.


-- 
Bill Guelker <wguelker@ch13stl.com>

On Tuesday 16 March 2004 12:19 pm, Bill Guelker wrote:
> Hello,
>
> I am not subscribed to the list, so please cc me on any replies!  My
> organization subscribes to a security advisory service that outsources
> remote penetration testing to qualys.com.  Our servers were recently
> scanned by qualys for the first time.  A host (running shorewall) acting
> as a firewall/gateway for an internal network was reported to be
> vulnerable to a packet fragmentation vulnerability which supposedly
> allows the destination tcp port of a given packet to be overwritten.  I
> have not had any success learning more about this alleged
> vulnerability.  Our web server, also running shorewall, was _not_
> reported to be vulnerable.  I am quoting the technical description of
> the vulnerability from qualys.com below.  Is this vulnerability common
> to all iptables firewalls like shorewall, or is there some element in my
> setup which has introduced it, or is the vulnerability identification
> from qualys bogus?  Thanks for any assistance you can offer!
>
With any stateful Linux firewall (Shorewall-based or not), fragments are 
reassembled by the Linux IP stack before the stateful firewall ever sees 
them. So this problem seems generic to iptables with connection tracking.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Tuesday 16 March 2004 01:01 pm, Tom Eastep wrote:
> With any stateful Linux firewall (Shorewall-based or not), fragments are
> reassembled by the Linux IP stack before the stateful firewall ever sees
> them. So this problem seems generic to iptables with connection tracking.
Note though that this means that Netfilter/Shorewall doesn''t rule on
the
packet until the fragments are reassembled. So I can''t see how one
could
exploit the fact that Linux appears to allow SYN packets to be fragmented. 

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Tue, 2004-03-16 at 16:26, Tom Eastep wrote:
> Note though that this means that Netfilter/Shorewall doesn''t rule
on the
> packet until the fragments are reassembled. So I can''t see how one
could
> exploit the fact that Linux appears to allow SYN packets to be fragmented. 
> 
> -Tom
Thanks, Tom.  I believed that this was the case, and I''m having an
awfully hard time getting specific details from qualys.com about how
they tested for this vulnerability in this case (i.e., what ports were
used, what exact result was obtained, etc.).  Of course, it doesn''t
help
that I''m working through a middle-man.  On the whole, ranking this as a
"serious" vulnerability in our systems seems to devalue what is
otherwise a thorough and helpful (and expensive) report.

And thanks for your work on Shorewall!  It really makes iptables easy.

-- 
Bill Guelker <wguelker@ch13stl.com>