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 <[email protected]>
http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash
XMPP: [email protected] | MSN: [email protected]
AIM: phrkonaleash | Yahoo: phrkonaleash
IRC: [email protected]/#srcedit,#teensonlinux,#plugaz and
countless other FOSS channels.
signature.asc
Description: This is a digitally signed message part.
--------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
