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@delphi.com>
http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash
XMPP: phrkonaleash@gmail.com | MSN: phrkonaleash@yahoo.com
AIM: phrkonaleash | Yahoo: phrkonaleash
IRC: PhrkOnLsh@irc.freenode.net/#srcedit,#teensonlinux,#plugaz and
countless other FOSS channels.
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)
