James Morris
2001-Oct-09 08:20 UTC
[netfilter-announce] Bug in Linux 2.4 / iptables MAC match module (fwd)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-465625440-1002298640=:29463 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <Pine.LNX.4.33.0110051717531.29463@localhost> ---------- Forwarded message ---------- Date: Mon, 8 Oct 2001 10:50:58 +0100 (BST) From: Chris Wilson <chris@netservers.co.uk> To: bugtraq@securityfocus.com Subject: Bug in Linux 2.4 / iptables MAC match module __ _ _ ___ --[ | \| |__| |/ _/ __ __ _ _ __ __ __ ]-- --[ | \ \ /o_| _\_ \/o_| _| | |/o_| _|_ \ ]-- --[ |_|\__\__|__|__/\__|_| \_/ \__|_|___/ ]-- --[ netservers security advisory 01-09-26 ]-- SUBJECT : Bug in Linux 2.4 / iptables MAC match module SUMMARY : MAC match module does not match small packets EFFECTS : Malicious users may bypass MAC-based DROP rules pcAnywhere does not function correctly if allowed by MAC address SOLUTION : Apply the attached patch from Harald Welte, Netfilter core developer, or wait for the next release of the Linux kernel. CREDITS : Harald Welte, Erick C. Jones, Netfilter team and users SUMMARY ------- The Linux 2.4 kernel includes a new and very powerful firewalling, NAT and packet mangling architecture called Netfilter. The main component of Netfilter is iptables, a generic structure for allowing firewall rules to perform NAT, mangle packets, and access custom extensions for packet matching and mangling. One of the extensions supplied by default is the MAC module, which matches packets travelling through the firewall on the basis of their MAC (ethernet hardware) address. This module offers administrators some protection against malicious internal (or directly connected) users who spoof or change their IP address. The MAC module does not correctly match very small packets. For example, small ping packets can be generated by the Unix command 'ping somehost -s 4', or similarly under Windows with 'ping somehost -l 4'. Netcat with the -u option can generate small UDP packets which exhibit the same problem. REPRODUCTION ------------ To reproduce the problem, you will need 2 machines: - Victim, which runs iptables. - Attacker, which can generate small ICMP or UDP packets. We have used the DNS names 'Victim' and 'Attacker' to represent the IP addresses of these machines, and AT:TA:CK:ER:00:00 as the MAC address of the attacker. Please substitute real values if attempting to reproduce this problem. On Victim, at a root prompt: victim# iptables -P INPUT ACCEPT victim# iptables -F INPUT victim# iptables -I INPUT -p icmp -m mac --mac-source AT:TA:CK:ER:00:00 -j DROP victim# iptables -L INPUT -v Chain INPUT (policy ACCEPT xxxx packets, xxxxxxx bytes) pkts bytes target prot opt in out source destination 0 0 DROP icmp -- any any anywhere anywhere MAC AT:TA:CK:ER:00:00 [note that the packet and byte counters are zero] On Attacker (assuming Attacker runs Linux or similar) attacker# ping -s 8 -c 1 Victim PING Victim (xx.xx.xx.xx) from xx.xx.xx.xx : 8(36) bytes of data. --- xx.xx.xx.xx ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss [the ping packets were dropped, correctly] On Victim again: victim# iptables -L INPUT -v Chain INPUT (policy ACCEPT 231 packets, 39475 bytes) pkts bytes target prot opt in out source destination 1 36 DROP icmp -- any any anywhere anywhere MAC 00:03:47:87:BA:C5 [note that the packet and byte counters have increased, the packet counter is showing 1 packet which is correct] Now back to Attacker: attacker# ping -s 4 -c 1 Victim PING Victim (xx.xx.xx.xx) from xx.xx.xx.xx : 4(32) bytes of data. 12 bytes from xx.xx.xx.xx: icmp_seq=0 ttl=255 --- xx.xx.xx.xx ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss [note that this time, the ping packet was replied to, not dropped by the rule] And finally, back to Victim: victim# iptables -L INPUT -v Chain INPUT (policy ACCEPT 231 packets, 39475 bytes) pkts bytes target prot opt in out source destination 1 32 DROP icmp -- any any anywhere anywhere MAC AT:TA:CK:ER:00:00 [note that the packet counters have not increased, the packet did not match the drop rule] IMPLICATIONS ------------>From a security point of view:- Malicious internal users may evade restrictions placed on their MAC address in some cases. For example, they might ping internal or external hosts to determine whether they are running, even though firewall rules disallow this. - They may also use small ICMP or UDP packets to leak information through the firewall, if no other rule prevents them from doing so. - Several applications use small ICMP or UDP packets, for example ping, netcat, and Symantec pcAnywhere. Administrators will not be able to restrict the use of these programs to certain known MAC addresses, because of this bug. This may result in lower overall security (especially as we know no complete workaround as yet). SOLUTION -------- Harald Welte, Netfilter core developer, has released a patch which we have verified to have fixed the problem in our case. The patch is very small and can be applied by hand (the patch may be wrapped by your mail client, so I have attached it as well). --- linux-2.4.9/net/ipv4/netfilter/ipt_mac.c Tue Oct 2 18:50:56 2001 +++ linux-2.4.9-ipt_mac-fix/net/ipv4/netfilter/ipt_mac.c Tue Oct 2 19:32:20 2001 @@ -20,7 +20,7 @@ /* Is mac pointer valid? */ return (skb->mac.raw >= skb->head - && skb->mac.raw < skb->head + skb->len - ETH_HLEN + && (skb->mac.raw + ETH_HLEN) <= skb->data /* If so, compare... */ && ((memcmp(skb->mac.ethernet->h_source, info->srcaddr, ETH_ALEN) == 0) ^ info->invert)); Harald Welte writes:> the patch has been submitted to David Miller just one minute ago.WORKAROUND ---------- The simplest, but least secure, workaround is to avoid matching by MAC address, but only match on IP address. This is common practice, but less secure than matching by MAC address. Another workaround is to use the latest version of iptables (1.2.3) from http://netfilter.samba.org. This includes a modules called "length" which can be used to match small packets. Some administrators might like to allow ICMP and/or UDP packets below a certain size with a command like this (UNTESTED): iptables -I INPUT -p icmp -m length --length 0:4 -j ACCEPT Note that using such a command will reduce the security of your iptables-protected hosts. In any case, a new version of iptables should be available soon which fixes this bug. CREDITS ------- Although we discovered this bug independently, James Morris of Netfilter was quick to point out that we were not the first. It appears that the bug was reported to Netfilter by Erick C Jones on 01/08/29. However, neither netfilter nor the Linux kernel was patched at this point. - http://lists.samba.org/pipermail/netfilter-devel/2001-August/002050.html - http://lists.samba.org/pipermail/netfilter-devel/2001-September/002278.html - http://lists.samba.org/pipermail/netfilter-devel/2001-September/002283.html We would like to thank: - The Netfilter team, both core and non-core, and Netfilter users for developing and testing this excellent packet filter system; - Harald Welte from Netfilter for his quick development of a patch and his generally friendly nature; - My boss, John McEleney, for discovering the bug. POLITICS -------- This advisory is RFpolicy compliant (http://www.wiretrip.net/rfp/policy.html). The bug was acknowledged by the Netfilter team within 5 days and quickly fixed. Thanks guys! Yet again open source beats closed source for rapid response. COPYRIGHT --------- This advisory is copyright (C) 2001 Netservers.co.uk. Redistribution is permitted provided the contents and text of the advisory are not modified in any way. This advisory has been modified and updated since its original distribution to the netfilter users list on 01/09/25. Ciao, Chris. -- ___ __ _ / __// / ,__(_)_ | Chris Wilson -- UNIX Firewall Lead Developer | / (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk | \ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 | --8323328-465625440-1002298640=:29463 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ipt_mac.c.patch" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.33.0110051717200.29463@localhost> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ipt_mac.c.patch" LS0tIGxpbnV4LTIuNC45L25ldC9pcHY0L25ldGZpbHRlci9pcHRfbWFjLmMJ VHVlIE9jdCAgMiAxODo1MDo1NiAyMDAxDQorKysgbGludXgtMi40LjktaXB0 X21hYy1maXgvbmV0L2lwdjQvbmV0ZmlsdGVyL2lwdF9tYWMuYwlUdWUgT2N0 ICAyIDE5OjMyOjIwIDIwMDENCkBAIC0yMCw3ICsyMCw3IEBADQogDQogICAg IC8qIElzIG1hYyBwb2ludGVyIHZhbGlkPyAqLw0KICAgICByZXR1cm4gKHNr Yi0+bWFjLnJhdyA+PSBza2ItPmhlYWQNCi0JICAgICYmIHNrYi0+bWFjLnJh dyA8IHNrYi0+aGVhZCArIHNrYi0+bGVuIC0gRVRIX0hMRU4NCisJICAgICYm IChza2ItPm1hYy5yYXcgKyBFVEhfSExFTikgPD0gc2tiLT5kYXRhDQogCSAg ICAvKiBJZiBzbywgY29tcGFyZS4uLiAqLw0KIAkgICAgJiYgKChtZW1jbXAo c2tiLT5tYWMuZXRoZXJuZXQtPmhfc291cmNlLCBpbmZvLT5zcmNhZGRyLCBF VEhfQUxFTikNCiAJCT09IDApIF4gaW5mby0+aW52ZXJ0KSk7DQo--8323328-465625440-1002298640=:29463--