Bug in Linux 2.4 / iptables MAC match module (fwd)
Jorge Sarmiento
jsarmiento@ccom.org
Tue, 9 Oct 2001 09:38:42 -0500
Does this parch work well in kernel 2.4.10 too? or is intended for kernel
2.4.9 only?
Best Regards!
Jorge S.
On Tuesday 09 October 2001 02:58 am, James Morris wrote:
> ---------- 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.