From security-advisories@FreeBSD.org Wed Feb 7 23:12:56 2001 From: FreeBSD Security Advisories To: BUGTRAQ@SECURITYFOCUS.COM Date: Wed, 7 Feb 2001 11:32:41 -0800 Subject: [BUGTRAQ] FreeBSD Security Advisory: FreeBSD-SA-01:08.ipfw [REVISED] -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-01:08 Security Advisory FreeBSD, Inc. Topic: ipfw/ip6fw allows bypassing of 'established' keyword [REVISED] Category: core Module: kernel Announced: 2001-01-23 Revised: 2001-02-07 Credits: Aragon Gouveia Affects: FreeBSD 3.x (all releases), FreeBSD 4.x (all releases), FreeBSD 3.5-STABLE and 4.2-STABLE prior to the correction date. Corrected: 2001-01-09 (FreeBSD 4.2-STABLE) Patch regression existed between 2001-02-01 and 2001-02-03 2001-01-12 (FreeBSD 3.5-STABLE) FreeBSD only: Yes 0. Revision History v1.0 2001-01-23 Initial release v1.1 2001-02-07 Note accidental reversion of changes in 4.2-STABLE I. Background ipfw is a system facility which allows IP packet filtering, redirecting, and traffic accounting. ip6fw is the corresponding utility for IPv6 networks, included in FreeBSD 4.0 and above. It is based on an old version of ipfw and does not contain as many features. II. Problem Description Due to overloading of the TCP reserved flags field, ipfw and ip6fw incorrectly treat all TCP packets with the ECE flag set as being part of an established TCP connection, which will therefore match a corresponding ipfw rule containing the 'established' qualifier, even if the packet is not part of an established connection. The ECE flag is not believed to be in common use on the Internet at present, but is part of an experimental extension to TCP for congestion notification. At least one other major operating system will emit TCP packets with the ECE flag set under certain operating conditions. Only systems which have enabled ipfw or ip6fw and use a ruleset containing TCP rules which make use of the 'established' qualifier, such as "allow tcp from any to any established", are vulnerable. The exact impact of the vulnerability on such systems is undetermined and depends on the exact ruleset in use. All released versions of FreeBSD prior to the correction date including FreeBSD 3.5.1 and FreeBSD 4.2 are vulnerable, but it was corrected prior to the (future) release of FreeBSD 4.3. Unfortunately, the security fix was accidentally reverted during a merge of ipfw changes from FreeBSD 5.0-CURRENT. The regression existed between the following dates: Problem introduced: Thu, 1 Feb 2001 12:25:10 -0800 (PST) Problem fixed: Sat, 3 Feb 2001 21:49:00 -0800 (PST) The affected revision was CVS revision 1.131.2.13 of /usr/src/sys/netinet/ip_fw.c and the corrrected revision is 1.131.2.14. Note that revisions prior to 1.131.2.11 are vulnerable to the problem described in this advisory. Version 1.131.2.11, and prior versions patched using the original patch distributed with the advisory are not vulnerable to the problem. To verify the CVS revision of your ip_fw.c file, perform the following command: mollari# ident /usr/src/sys/netinet/ip_fw.c /usr/src/sys/netinet/ip_fw.c: $FreeBSD: src/sys/netinet/ip_fw.c,v 1.131.2.14 2001/02/04 05:48:59 rwatson Exp $ If you have revision 1.131.2.13, download the "regression" patch described in section V below. III. Impact Remote attackers who construct TCP packets with the ECE flag set may bypass certain ipfw rules, allowing them to potentially circumvent the firewall. The regression described above is actually a more serious vulnerability: instead of only allowing packets with the ECE flag set, typically requiring special tools, all TCP packets regardless of flags would be passed by the ipfw rule. IV. Workaround Because the vulnerability only affects 'established' rules and ECE- flagged TCP packets, this vulnerability can be removed by adjusting the system's rulesets. In general, it is possible to express most 'established' rules in terms of a general TCP rule (with no TCP flag qualifications) and a 'setup' rule, but may require some restructuring and renumbering of the ruleset. V. Solution One of the following: 1) Upgrade the vulnerable FreeBSD system to FreeBSD 3.5-STABLE, or or 4.2-STABLE after the correction date. 2) Patch your present system by downloading the relevant patch from the below location: [FreeBSD 4.x - patch for regression introduced on 2001-02-01] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.2-regression.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.2-regression.patch.asc [FreeBSD 4.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch.asc [FreeBSD 3.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch.asc Verify the detached PGP signature using your PGP utility. Execute the following commands as root: # cd /usr/src # patch -p < /path/to/patch # cp /usr/src/sys/netinet/tcp.h /usr/src/sys/netinet/ip_fw.h /usr/include/netinet/ # cd /usr/src/sbin/ipfw # make depend && make all install # cd /usr/src/sys/modules/ipfw # make depend && make all install For 4.x systems, perform the following additional steps: # cp /usr/src/sys/netinet6/ip6_fw.h /usr/include/netinet6/ # cd /usr/src/sbin/ip6fw # make depend && make all install # cd /usr/src/sys/modules/ip6fw # make depend && make all install NOTE: The ip6fw patches have not yet been tested but are believed to be correct. The ip6fw software is not currently maintained and may be removed in a future release. If the system is using the ipfw or ip6fw kernel modules (see kldstat(8)), the module may be unloaded and the corrected module loaded into the kernel using kldload(8)/kldunload(8). This will require that the firewall rules be reloaded, usually be executing the /etc/rc.firewall script. Because the loading of the ipfw or ip6fw module will result in the system denying all packets by default, this should only be attempted when accessing the system via console or by careful use of a command such as: # kldload ipfw && sh /etc/rc.firewall which performs both operations sequentially. Otherwise, if the system has ipfw or ip6fw compiled into the kernel, the kernel will also have to be recompiled and installed, and the system will have to be rebooted for the changes to take effect. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBOoGip1UuHi5z0oilAQGwNQP/ROCEDN4TCR147vZGfYEMuDOf9L3QS5u1 fT/kgz/h+wpHOr5jf6MAxkgxQCjkEBhdtp8OdWsXXY6/3RYfAbqnFGKFQw71XalF 7iUXrmz8jQ9nmmW7BaMn0+omSwhmWgQkIL3IjZx7krND/X9OIvGCXk7Yk9+XdpIH OVshiguHbl4= =iSD2 -----END PGP SIGNATURE-----