Bug 65594 (CVE-2005-0449)

<!-- SBZ_reproduce  -->
n/a

Created attachment 28285 [details]
fragment-oops.patch

patch that was committed to bitkeeper (url above)...longish

uhhh... are you sure this is the right patch? 
 
The netdev thread Martin is referring to indeed refers to a remotely 
triggerable oops in the fragment handling code, but the patch is a two-liner 
and fortunately a lot less intrusive than the one you attached here. 

Created attachment 28686 [details]
Patch from netdev

i did not really follow the mailing list thread fully I guess. 
 
He references a cset from herbert xu directly, I suspect this  
might be security relevant too? Is this a different issue? 

That patch is mildly security relevant. ip_conntrack does fragment 
reassembly, and this patch makes sure that fragments from say the 
outside world aren't added to a fragment chain of a packet being 
received from inside. 
 
I think this is a fairly theoretical problem, as the attacker would 
have to guess the fragment ID (16 bit), transport layer checksum (16 bit) 
and hit a timing window of a few milliseconds during which ip_conntrack 
is receiving all the fragments. 
 
It's probably worth fixing, but not in a security update, IMHO. 

ok, then we only will use the 2 liner patch and have the other fixed via 
mainline and new products. 

I agree with Olaf that the multiple fragment queue attack is too theoretical
for a security update.

From: Olaf Kirch <okir@suse.de> 
To: Herbert Xu <herbert@gondor.apana.org.au> 
Cc: Vendor Security <vendor-sec@lst.de> 
Subject: Re: [vendor-sec] Linux kernel: remote oops/firewall bypass 
User-Agent: Mutt/1.5.6i 
Errors-To: vendor-sec-admin@lst.de 
Date: Wed, 23 Feb 2005 10:47:40 +0100 
 
On Wed, Feb 23, 2005 at 08:35:09PM +1100, Herbert Xu wrote: 
> 1) All fragments are collected in PREROUTING by conntrack. 
> 2) The packet passes through routing/firewalling. 
> 3) It is refragmented on output. 
> 4) The fragments are colleted again in POSTROUTING. 
 
Oh, I see. I wasn't aware that netfilter does reassembly twice. 
 
> I don't know which patch Martin was referring to.  The patch that 
> addresses the problem is the one by Patrick McHardy that creates 
> private fragment queues. 
 
Yes, that's the patch. With your explanation above I understand 
why it fixes the problem. 
 
Thanks, 
Olaf 
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play 
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax 
 

From: Mark J Cox <mjc@redhat.com> 
To: Herbert Xu <herbert@gondor.apana.org.au> 
Cc: Olaf Kirch <okir@suse.de>, Vendor Security <vendor-sec@lst.de> 
Subject: Re: [vendor-sec] Linux kernel: remote oops/firewall bypass 
Errors-To: vendor-sec-admin@lst.de 
Date: Wed, 23 Feb 2005 13:48:58 +0000 (GMT) 
 
>The idea is to send n fragments followed by a repeat of the head 
>fragment.  Should the head fragment be received in PREROUTING 
>conntrack while the complete packet is being processed in 
>POSTROUTING or one of the other locations requiring reassembly, 
>then you'll end up with a packet with a NULL dst.  This will 
>lead to a crash. 
 
http://linux.bkbits.net:8080/linux-2.6/cset@41f8843a8ZMCNuP3meYAYnnXd3CO_g 
 
So this is what I imagine got issued CAN-2005-0449 after being mentioned 
in an Ubuntu advisory (seems to match since it mentions kABI break). 
http://marc.theaimsgroup.com/?l=full-disclosure&m=110846102231365&w=2 
SMP, linux-2.6 only. 
 
>This is a different issue, which probably more serious, as it 
>allows you to crash a host remotely using bad fragments. 
>AFAIK it's easily reproduceable. The patch by Herbert is a two-liner, 
>and is buried somewhere inside this thread. 
 
http://linux.bkbits.net:8080/linux-2.6/cset@41f59581p1swNaow4K1aBglV-q2jfQ 
 
So for this separate issue - not sure if this got fixed by Ubuntu or not, 
but it needs a different CVE name.  affects only certain NICS, linux-2.6 
only. 
 
 

From: Mark J Cox <mjc@redhat.com> 
To: Herbert Xu <herbert@gondor.apana.org.au> 
Cc: Olaf Kirch <okir@suse.de>, Vendor Security <vendor-sec@lst.de> 
Subject: Re: [vendor-sec] Linux kernel: remote oops/firewall bypass 
Errors-To: vendor-sec-admin@lst.de 
Date: Thu, 24 Feb 2005 10:41:26 +0000 (GMT) 
 
>http://linux.bkbits.net:8080/linux-2.6/cset@41f59581p1swNaow4K1aBglV-q2jfQ 
> 
>So for this separate issue - not sure if this got fixed by Ubuntu or not, 
>but it needs a different CVE name.  affects only certain NICS, linux-2.6 
>only. 
 
Use CAN-2005-0209 for that issue. 
 
Herbert also mentioned a dsk leak problem which can lead to memory 
exhaustion over time: 
 
http://linux.bkbits.net:8080/linux-2.5/cset@41fd96c39V0t4MxKFxE1aZn2f4b5UA 
http://linux.bkbits.net:8080/linux-2.5/cset@41fdb84aBJklcjU85o1N1_dsch6HBw 
 
Use CAN-2005-0210 for that issue. 
_______________________________________________ 
Vendor Security mailing list 
 

olaf to apply the 4 patches inside. 

Added patches to SLES9 SP1, SLES9 SP2 and SL_92 branches. 
Assigning back to security-team 

surface for QA 

-> tracking 

updates + advisory released. 
 
could not reproduce problem in QA setting :/ 

The setup used by QA:

server: 9.3 RC1 with IP 192.168.1.2 using MTU 1000

router: SLES9 with vunlerable kernel running as router with
        IP 192.168.1.1 using MTU 1000
        IP 10.10.3.57 using MTU 1500

client: 9.1 with IP 10.10.2.8 using MTU 1500
        and host route for 192.168.1.2 via 10.10.3.57
   
uname from the router:
Linux sinope 2.6.5-7.145-default #1 SMP Thu Jan 27 09:19:29 UTC 2005 ia64 ia64
ia64 GNU/Linux

The client mounted a share from the server with

mount -o udp 192.168.1.2:/space /mnt

and copied 5 GB of data onto the writeable share.

The traffic monitored on the router showed packets like:

11:15:24.699063 IP 10.10.2.8 > 192.168.1.2: udp
11:15:24.700126 IP 192.168.1.2.2049 > 10.10.2.8.800: UDP, length: 136
11:15:24.701734 IP 10.10.2.8.800 > 192.168.1.2.2049: UDP, length: 32900
11:15:24.702555 IP 10.10.2.8 > 192.168.1.2: udp
11:15:24.702666 IP 10.10.2.8 > 192.168.1.2: udp
11:15:24.702782 IP 192.168.1.2.2049 > 10.10.2.8.800: UDP, length: 136

The data was copied back from the server to the client (again 5 GB).

Neither dmesg nor /var/log/warn showed errors on the router.

CVE-2005-0449: CVSS v2 Base Score: 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C)