Hi Dave!
Attached is a (proposed) patch to fix the problem described in the
attached (should be on bugtraq by now) advisory.
I'm not entirely sure if my idea behind this patch is correct,
or if there are any more sophisticated checks you recommend for finding out
if this skb has a valid mac address at the skb->mac.raw pointer.
Please have a look and apply or comment.
Thanks in advance,
Harald.
--- 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));
--
Live long and prosper
- Harald Welte / laforge@xxxxxxxxxxxx http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
--- Begin Message ---
Dear Netfilter Team,
Thank you very much for your hard work in providing a world-leading
firewall solution for free on Linux systems. Unfortunately we think we
have discovered a bug in the Netfilter/iptables MAC address matching
module.
Please could you let us know as soon as you have some information
regarding this bug. We very much hope to hear from you before Wednesday
3rd October 2001. If not then we shall be forced, reluctantly, to publish
this advisory.
Thank you again for your help and hard work.
Yours sincerely,
Chris Wilson, NetServers lead developer.
-------------------------------------------------------------------------
__ _ _ ___
--[ | \| |__| |/ _/ __ __ _ _ __ __ __ ]--
--[ | \ \ /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
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 4 Victim
PING Victim (xx.xx.xx.xx) from xx.xx.xx.xx : 8(36) bytes of data.
--- xx.xx.xx.xx ping statistics ---
4 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
4 144 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 4 packets which is correct]
Now back to Attacker:
attacker# ping -s 4 -c 4 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
12 bytes from xx.xx.xx.xx: icmp_seq=1 ttl=255
12 bytes from xx.xx.xx.xx: icmp_seq=2 ttl=255
12 bytes from xx.xx.xx.xx: icmp_seq=3 ttl=255
--- xx.xx.xx.xx ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
[note that this time, all packets were replied to, whereas before they
were 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
4 144 DROP icmp -- any any anywhere anywhere
MAC AT:TA:CK:ER:00:00
[note that the packet counters have not increased, the packets 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).
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.
SOLUTION
--------
Wait for a patch from the Netfilter developers.
POLITICS
--------
This advisory is RFpolicy compliant
(http://www.wiretrip.net/rfp/policy.html). If we do not receive any
acknowledgement from the Netfilter team within 5 working days (by 9am GMT
on Wednesday 3rd October) we will assume that they are not interested and
publish this advisory on Bugtraq without a proper solution or workaround.
We really hope that they will contact us and such measures will not be
necessary.
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.
Ciao, Chris.
--
___ __ _
/ __// / ,__(_)_ | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |
--- End Message ---
foo
Description: Mail describing reasons behind patch
|