Null pointer dereference in icmp_send

Null pointer dereference in icmp_send

[Aristide Fattori]

Hi everybody,

in function icmp_send() (net/ipv4/icmp.c), the parameter passed to
dev_net() function is not properly validated. This can lead to a NULL
pointer dereference that crashes the kernel. The bug can be triggered
remotely, by flooding the target with fragmented IPv4 packets.
Important fields in the IP packet are:
 * Flags: the MF flag must be set.
 * Fragment ID: using pseudo-random values for this field quickly
fills fragmented queues in the victim's kernel, as it is unable to
easily reassemble received packets.
 * TOS: using pseudo-random values for this field triggers the
creation of more than one route cache entry for the same destination
address, increasing the chances of incurring in the error condition
described before.
Other fields of the packet do not really matter, and they can be set
to arbitrary values.

If you are interested, we can provide a small and very dirty python
script that easily triggers the error condition.

Greetings,
Aristide Fattori
Roberto Paleari

-- 
GnuPG Key on keyserver.pgp.com ID 0x25578128
http://security.dico.unimi.it/~joystick/

Re: Null pointer dereference in icmp_send

[David Miller]

From: Aristide Fattori <joystick@idea.sec.dico.unimi.it>
Date: Mon, 16 May 2011 23:06:32 +0200

> in function icmp_send() (net/ipv4/icmp.c), the parameter passed to
> dev_net() function is not properly validated.

It doesn't need to be.

If 'rt' is not NULL, then rt->dst.dev is always not NULL and
therefore no checks are necessary.

Re: Null pointer dereference in icmp_send

[Eric Dumazet]

Le lundi 16 mai 2011 à 23:06 +0200, Aristide Fattori a écrit :
> Hi everybody,
> 
> in function icmp_send() (net/ipv4/icmp.c), the parameter passed to
> dev_net() function is not properly validated. This can lead to a NULL
> pointer dereference that crashes the kernel. The bug can be triggered
> remotely, by flooding the target with fragmented IPv4 packets.
> Important fields in the IP packet are:
>  * Flags: the MF flag must be set.
>  * Fragment ID: using pseudo-random values for this field quickly
> fills fragmented queues in the victim's kernel, as it is unable to
> easily reassemble received packets.
>  * TOS: using pseudo-random values for this field triggers the
> creation of more than one route cache entry for the same destination
> address, increasing the chances of incurring in the error condition
> described before.
> Other fields of the packet do not really matter, and they can be set
> to arbitrary values.
> 
> If you are interested, we can provide a small and very dirty python
> script that easily triggers the error condition.
> 

Hi

You forgot to tell us which linux version you used ?

We had some fixes lately in this area.

Thanks

Re: Null pointer dereference in icmp_send

[Eric Dumazet]

Le lundi 16 mai 2011 à 23:27 +0200, Eric Dumazet a écrit :
> Le lundi 16 mai 2011 à 23:06 +0200, Aristide Fattori a écrit :
> > Hi everybody,
> > 
> > in function icmp_send() (net/ipv4/icmp.c), the parameter passed to
> > dev_net() function is not properly validated. This can lead to a NULL
> > pointer dereference that crashes the kernel. The bug can be triggered
> > remotely, by flooding the target with fragmented IPv4 packets.
> > Important fields in the IP packet are:
> >  * Flags: the MF flag must be set.
> >  * Fragment ID: using pseudo-random values for this field quickly
> > fills fragmented queues in the victim's kernel, as it is unable to
> > easily reassemble received packets.
> >  * TOS: using pseudo-random values for this field triggers the
> > creation of more than one route cache entry for the same destination
> > address, increasing the chances of incurring in the error condition
> > described before.
> > Other fields of the packet do not really matter, and they can be set
> > to arbitrary values.
> > 
> > If you are interested, we can provide a small and very dirty python
> > script that easily triggers the error condition.
> > 
> 
> Hi
> 
> You forgot to tell us which linux version you used ?
> 
> We had some fixes lately in this area.
> 

Since its late here I should give more information :)

We fixed a problem 12 days ago, please check following patch

http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=64f3b9e203bd06855072e295557dca1485a2ecba

It is scheduled for linux-2.6.38 stable tree as well


net: ip_expire() must revalidate route

Commit 4a94445c9a5c (net: Use ip_route_input_noref() in input path)
added a bug in IP defragmentation handling, in case timeout is fired.

When a frame is defragmented, we use last skb dst field when building
final skb. Its dst is valid, since we are in rcu read section.

But if a timeout occurs, we take first queued fragment to build one ICMP
TIME EXCEEDED message. Problem is all queued skb have weak dst pointers,
since we escaped RCU critical section after their queueing. icmp_send()
might dereference a now freed (and possibly reused) part of memory.

Calling skb_dst_drop() and ip_route_input_noref() to revalidate route is
the only possible choice.

Re: Null pointer dereference in icmp_send

[Aristide Fattori]

Hi Eric,

On Mon, May 16, 2011 at 11:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 16 mai 2011 à 23:27 +0200, Eric Dumazet a écrit :
>> You forgot to tell us which linux version you used ?

Sorry about that, we verified the bug in versions 2.6.38.3, 2.6.38.4
and 2.6.38.6, but we didn't check the svn version :-)

> ...
> But if a timeout occurs, we take first queued fragment to build one ICMP
> TIME EXCEEDED message. Problem is all queued skb have weak dst pointers,
> ...

At a first glance, it appears we identified the same bug you already
fixed. If you want to double check, we can send you the "long version
report" that we submitted at first to security@kernel.org and
david@davemloft.net.

> It is scheduled for linux-2.6.38 stable tree as well

Good job! :-)

-- 
GnuPG Key on keyserver.pgp.com ID 0x25578128
http://security.dico.unimi.it/~joystick/

Re: Null pointer dereference in icmp_send

[Eric Dumazet]

Le mardi 17 mai 2011 à 09:31 +0200, Aristide Fattori a écrit :

> At a first glance, it appears we identified the same bug you already
> fixed. If you want to double check, we can send you the "long version
> report" that we submitted at first to security@kernel.org and
> david@davemloft.net.

Well, why not, please send it to me only.

Thanks