[PATCH] fix bug in mac address matching code [bugtraq-advisory]
Harald Welte
laforge@gnumonks.org
Fri, 5 Oct 2001 17:45:10 +0200
--61jdw2sOBCFtR2d/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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@gnumonks.org 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+(*)
--61jdw2sOBCFtR2d/
Content-Type: message/rfc822
Content-Disposition: inline
Return-Path:X-Sieve: cmu-sieve 2.0
Received: from samba.sourceforge.net ([198.186.203.85] helo=lists.samba.org)
by coruscant.gnumonks.org with esmtp (Exim 3.33 #1)
id 15lwdM-0003rg-00
for laforge@gnumonks.org; Tue, 25 Sep 2001 20:08:41 +0200
Received: from va.samba.org (localhost [127.0.0.1])
by lists.samba.org (Postfix) with ESMTP
id 26AD24B14; Tue, 25 Sep 2001 11:02:08 -0700 (PDT)
Delivered-To: netfilter@lists.samba.org
Received: from mail1.netservers.co.uk (mail1.netservers.co.uk
[193.115.249.2]) by lists.samba.org (Postfix) with ESMTP id B27924C2F
for <netfilter@lists.samba.org>; Tue, 25 Sep 2001 11:00:52 -0700 (PDT)
Received: from server (firewall1.cammail.net [193.115.249.1]) by
mail1.netservers.co.uk (8.12.0/8.12.0) with ESMTP id f8PI3aV9011365;
Tue, 25 Sep 2001 19:03:36 +0100
From: Chris Wilson <chris@netservers.co.uk>
X-X-Sender: <chris@localhost>
To: <netfilter@lists.samba.org>
Cc: <john@camcom.co.uk>
Subject: Bug in Linux 2.4 / iptables MAC match module
Message-ID: <Pine.LNX.4.33.0109251901460.5690-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by Netservers.co.uk (http://netservers.co.uk/)
Sender: netfilter-admin@lists.samba.org
Errors-To: netfilter-admin@lists.samba.org
X-BeenThere: netfilter@lists.samba.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:netfilter-request@lists.samba.org?subject=help>
List-Post: <mailto:netfilter@lists.samba.org>
List-Subscribe: <http://lists.samba.org/listinfo/netfilter>,
<mailto:netfilter-request@lists.samba.org?subject=subscribe>
List-Id: netfilter user discussion list <netfilter.lists.samba.org>
List-Unsubscribe: <http://lists.samba.org/listinfo/netfilter>,
<mailto:netfilter-request@lists.samba.org?subject=unsubscribe>
List-Archive: <http://lists.samba.org/pipermail/netfilter/>
Date: Tue, 25 Sep 2001 19:03:45 +0100 (BST)
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 |
--61jdw2sOBCFtR2d/
Content-Type: text/plain; charset=us-ascii
Content-Description: Mail describing reasons behind patch
Content-Disposition: attachment; filename=foo
>From laforge@gnumonks.org Tue Oct 2 19:57:28 2001
Date: Tue, 2 Oct 2001 19:57:28 +0200
From: Harald Welte <laforge@gnumonks.org>
To: Chris Wilson <chris@netservers.co.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>, Marc Boucher <marc@mbsi.ca>,
James Morris <jmorris@intercode.com.au>,
Netfilter Development Mailinglist <netfilter-devel@lists.samba.org>
Subject: Re: Bug in Linux 2.4 / iptables MAC match module
Message-ID: <20011002195727.H3206@naboo.gnumonks.org>
Mail-Followup-To: Harald Welte <laforge@gnumonks.org>,
Chris Wilson <chris@netservers.co.uk>,
Rusty Russell <rusty@rustcorp.com.au>, Marc Boucher <marc@mbsi.ca>,
James Morris <jmorris@intercode.com.au>,
Netfilter Development Mailinglist <netfilter-devel@lists.samba.org>
References: <Pine.LNX.4.33.0109251901460.5690-100000@localhost>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="7DO5AaGCk89r4vaK"
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <Pine.LNX.4.33.0109251901460.5690-100000@localhost>; from chris@netservers.co.uk on Tue, Sep 25, 2001 at 07:03:45PM +0100
X-Operating-System: Linux naboo.gnumonks.org 2.4.9
X-Date: Today is Setting Orange, the 56th day of Bureaucracy in the YOLD 3167
Status: RO
Content-Length: 2931
Lines: 83
--7DO5AaGCk89r4vaK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Sep 25, 2001 at 07:03:45PM +0100, Chris Wilson wrote:
> 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.
ok. There is news about this now.=20
As far as I understood the problem, the problematic piece of code was:
/* Is mac pointer valid? */
return (skb->mac.raw >=3D skb->head
&& skb->mac.raw < skb->head + skb->len - ETH_HLEN
/* If so, compare... */
&& ((memcmp(skb->mac.ethernet->h_source, info->srcaddr, ETH_ALEN)
=3D=3D 0) ^ info->invert));
skb->head points to first byte of the layer 2 packet
skb->mac.raw points to first byte of destination mac address
skb->data points to first byte of layer 3 packet (=3D=3D ip header)
skb->len length of layer three packet (layer 2 payload) in bytes
ETH_HLEN length of layer 2 header (14 bytes, 2*6byte mac + 2byte l3prot)
The first check checks, if the pointer to the beginning of the mac address
is greater or equal than the skb->head. That's ok.
The second check, however does something strange. It checks if the pointer=
to
the beginning of the mac address (first byte of destination mac) is smaller
than skb->head + skb->len - ETH_HLEN. This doesn't seem to make sense to m=
e.
I guess the intention was to check if the whole mac address fits within the
skb's valid data area. But this is not what was done.
skb->head + skb->len does not point to the end of the packet,
skb->data + skb->len would do. The original calculation "head + len" leads=
to
the assumption the packet is shorter than it really is (by "skb->data - skb=
->head" bytes short).
I think it's better to check if skb->mac.raw + ETH_HLEN <=3D skb->data. Thi=
s is
what attached patch does.
Could you please verify that your problem is gone with attached patch?
Thanks.
> Chris Wilson, NetServers lead developer.
--=20
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-=
=20
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
--7DO5AaGCk89r4vaK
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7ugAHXaXGVTD0i/8RAsxgAJ4knuljKePvMqz5f/SI5yc1G4a0TQCgmgBr
MAj9vLeWqv/5zxvH78AjaC0=
=LmeI
-----END PGP SIGNATURE-----
--7DO5AaGCk89r4vaK--
--61jdw2sOBCFtR2d/--