Linux Kernel Security (tun/net and Null Pointer Dereferences provide 4 hour encroachment via Script Fuzz)

[Ryan Rix]

On Sun 19 July 2009 10:33:00 am Lisa Kachold wrote:
> This code looks perfectly acceptable, right?  Well, it is, until the
> compiler takes this into its hands. While optimizing the code, the
> compiler will see that the variable has already been assigned and will
> actually remove the if block (the check if tun is NULL) completely
> from the resulting compiled code. In other words, the compiler will
> introduce the vulnerability to the binary code, which didn't exist in
> the source code. This will cause the kernel to try to read/write data
> from 0x00000000, which the attacker can map to userland – and this
> finally pwns the box

No, it reads from (NULL+offsetof(sk))
Doing pointer arithetic on NULL is perfectly legal (but not dereferencing 
NULL), and basically that's what this relies on.
sk = tun->sk;
is the same as writing
sk = *(&tun+offsetof(sk)); // idk what that offset is, let's say it's 42 bytes
which, in the case would be dereferencing (0x00000000+0x00000042) which is 
perfectly legal and accessible memory. Therein lies the problem.

Some say it is a problem with the compiler optimisation, some say it's a 
kernel bug. Both should be fixed, imo.

Ryan

-- 
---
Ryan Rix
(623)-826-0051

The problem here (as someon else stated) is that when multiple dists
use the same package format it only gives a "false sense of compatibility".
	-- Stephen Carpenter <sjc at delphi.com>

http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash
XMPP: phrkonaleash at gmail.com          | MSN: phrkonaleash at yahoo.com
AIM:  phrkonaleash                    | Yahoo: phrkonaleash
IRC:  PhrkOnLsh at irc.freenode.net/#srcedit,#teensonlinux,#plugaz and
      countless other FOSS channels.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20090719/8e41ed30/attachment.pgp