PF Scrub
Hello All, Just a quick question. I am doing scrub on my upstream OpenBSD server. Will this work as a temporary workaround for this security flaw (below) in FreeBSD? Regards Mark -Forwarded Message- From: FreeBSD Security Advisories [EMAIL PROTECTED] To: FreeBSD Security Advisories [EMAIL PROTECTED] Subject: FreeBSD Security Advisory FreeBSD-SA-04:04.tcp Date: Tue, 02 Mar 2004 11:55:44 -0800 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-04:04.tcp Security Advisory The FreeBSD Project Topic: many out-of-sequence TCP packets denial-of-service Category: core Module: kernel Announced: 2004-03-02 Credits:iDEFENSE Affects:All FreeBSD releases Corrected: 2004-03-02 17:19:18 UTC (RELENG_4) 2004-03-02 17:24:46 UTC (RELENG_5_2, 5.2.1-RELEASE-p1) 2004-03-02 17:26:33 UTC (RELENG_4_9, 4.9-RELEASE-p3) 2004-03-02 17:27:47 UTC (RELENG_4_8, 4.8-RELEASE-p16) CVE Name: CAN-2004-0171 FreeBSD only: NO I. Background The Transmission Control Protocol (TCP) of the TCP/IP protocol suite provides a connection-oriented, reliable, sequence-preserving data stream service. When network packets making up a TCP stream (``TCP segments'') are received out-of-sequence, they are maintained in a reassembly queue by the destination system until they can be re-ordered and re-assembled. II. Problem Description FreeBSD does not limit the number of TCP segments that may be held in a reassembly queue. III. Impact A remote attacker may conduct a low-bandwidth denial-of-service attack against a machine providing services based on TCP (there are many such services, including HTTP, SMTP, and FTP). By sending many out-of-sequence TCP segments, the attacker can cause the target machine to consume all available memory buffers (``mbufs''), likely leading to a system crash. IV. Workaround It may be possible to mitigate some denial-of-service attacks by implementing timeouts at the application level. V. Solution Do one of the following: 1) Upgrade your vulnerable system to 4-STABLE, or to the RELENG_5_2, RELENG_4_9, or RELENG_4_8 security branch dated after the correction date. OR 2) Patch your present system: The following patch has been verified to apply to FreeBSD 4.x and 5.x systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 5.2] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc [FreeBSD 4.8, 4.9] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp47.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp47.patch.asc b) Apply the patch. # cd /usr/src # patch /path/to/patch c) Recompile your kernel as described in URL:http://www.freebsd.org/handbook/kernelconfig.html and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - - RELENG_4 src/UPDATING 1.73.2.90 src/sys/conf/newvers.sh 1.44.2.33 src/sys/netinet/tcp_input.c 1.107.2.40 src/sys/netinet/tcp_subr.c1.73.2.33 src/sys/netinet/tcp_var.h 1.56.2.15 RELENG_5_2 src/UPDATING 1.282.2.9 src/sys/conf/newvers.sh1.56.2.8 src/sys/netinet/tcp_input.c 1.217.2.2 src/sys/netinet/tcp_subr.c1.169.2.4 src/sys/netinet/tcp_var.h 1.93.2.2 RELENG_4_9 src/UPDATING 1.73.2.89.2.4 src/sys/conf/newvers.sh 1.44.2.32.2.4 src/sys/netinet/tcp_input.c 1.107.2.38.2.1 src/sys/netinet/tcp_subr.c1.73.2.31.4.1 src/sys/netinet/tcp_var.h 1.56.2.13.4.1 RELENG_4_8 src/UPDATING 1.73.2.80.2.19 src/sys/conf/newvers.sh 1.44.2.29.2.17 src/sys/netinet/tcp_input.c 1.107.2.37.2.1 src/sys/netinet/tcp_subr.c1.73.2.31.2.1 src/sys/netinet/tcp_var.h 1.56.2.13.2.1 -
Re: PF Scrub
On Wed, Mar 03, 2004 at 11:40:03AM +0200, Mark Bojara wrote: Just a quick question. I am doing scrub on my upstream OpenBSD server. Will this work as a temporary workaround for this security flaw (below) in FreeBSD? No, scrub does IP reassembly (assembling IP fragments into complete IP packets). But the problem you refer to is about out-of-order TCP segments. It's a somewhat similar scheme (TCP reassembly does something similar to IP reassembly), but on a different level. I think doing this in pf scrub for TCP segments is still on the todo list (or once was, at least) ;) Daniel
Re: State table across reboots
On Tue, Mar 02, 2004 at 09:27:48AM -0800, Getchell, Adam wrote: I'm under the impression pf keeps the state table across reboots, but Googling for it just gives Darren Reed's response: http://monkey.org/openbsd/archive/misc/0201/msg01135.html Does it? No, the state table is not stored in a file and reloaded on reboot, though that wouldn't be hard to do (the ioctl API is there already), I guess it's just not generally useful enough. If you filter TCP statefully and create state only on SYN packets (using flags S/SA keep state), a reboot will stall or reset your existing connections. If you allow non-SYN packets to create state (without flags S/SA), the next packet seen after reboot for an existing connection will create a new state entry, and the connections continues to work (assuming the next packet, which can be coming from either direction, on more than one interface possibly, actually matches a pass keep state rule). Some features like modulate state, syn-proxy or window scaling support only work when pf creates state on the initial SYN and sees the TCP handshake. So creating state from non-SYN will not work properly when these features are used/needed. Daniel
Re: PF Scrub
It might be worth adding that the traffic exploiting that problem is not invalid in any sense. TCP segments can arrive out-of-order in legitimate usage, too. For instance, individual TCP packets of one connection can take different paths to your peer, so a higher fragment may very well arrive before a lower one. If that was not expected, there would be no need for TCP reassembly at all. So, reassembling TCP segments is needed, unless you're willing to break perfectly legitimate connections. But an attacker should not be able to grow the reassembly queue up to the point where you crash because you run out of memory. Finding a good strategy to decide what queue entries to drop at what point is not trivial. I think we'll wait and see what strategies work best in the TCP/IP stack, and use that experience if/when implementing TCP reassembly in pf scrub. Daniel
Anti-Spoofing - no-route
What is the difference between the 2 block'ing rules below
... table garbage { 127/8, 10/8, 172.16/12, 192.168/16, 255.255.255.255/32 }
... block in log quick on $exIF from no-route to any
... block in log quick on $exIF from garbage to any
i.e. what does no-route expand to.
The manual entry talks about no-route being any address that is not
currently routable. However, as I am routing 192.168.0.0/24 internally,
does that not get excluded? I certainly do NOT want to see a source
address coming in from the outside with the same IPs as my own internal
addresses.
Are these rules redundant or complimentary?
Thanks - Damian
NOW - if my short explanation was too brief or poorly worded
PF filters between an external set of IPs, say 202.202.202.0/24 and an
internal network, 192.168.0.0/24.
Let's assume I want a bidirectional NAT of 202.202.202.145 on the
host which, behind the firewall is 192.168.0.145. That is, I want
the outside world to think my host is 202.202.202.145.
The relevant pieces of /etc/pf.conf are
... exIF=de0
... mail=192.168.0.145
... table garbage { 127/8, 10/8, 172.16/12, 192.168/16, 255.255.255.255/32 }
... scrub in all
... # Expose A Host
... binat on $exIF from 192.168.0.145 to any - 202.202.202.145
... # No spoofing
... block in log quick on $exIF from no-route to any
... block in log quick on $exIF from garbage to any
... # Pass through rules follow later
... pass in quick on $exIF\
...proto tcp from any to 192.168.0.145 port 25 keep state
P.S. As soon as I saw the 'caveat' on the antispoof rule, I got worried.
When I couldn't find examples, I just gave up on it.
Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468 | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer
Re: Anti-Spoofing - no-route
On Wed, Mar 03, 2004 at 09:24:41PM +1100, Damian McGuckin wrote:
What is the difference between the 2 block'ing rules below
... table garbage { 127/8, 10/8, 172.16/12, 192.168/16, 255.255.255.255/32 }
... block in log quick on $exIF from no-route to any
... block in log quick on $exIF from garbage to any
i.e. what does no-route expand to.
They are very different, no-route doesn't expand at all, but is
evaluated at run-time, matching addresses which the pf box doesn't have
routes to at the time of evaluation.
If your pf box has a default route configured, no-route is useless, as
you have a route to any address (through that default gateway). It only
makes sense on hosts without a default route. And there's no relation to
'unroutable' addresses like 192.168/16 or 10/8 at all, your host may
very well have routes to such networks.
On hosts without a default route, however, no-route can be used for
antispoof-like constructs. For instance, you might want to block
incoming packets from sources that you can't reply to, due to a lacking
route. No matter whether they be reserved addresses like 10/8 or not.
Daniel
Re: State table across reboots
On Tue, Mar 02, 2004 at 09:27:48AM -0800, Getchell, Adam wrote: I'm under the impression pf keeps the state table across reboots, but It does not.
