Date: Tue, 25 Oct 2011 12:06:25 +0200
From: Tavis Ormandy <taviso@...xchg8b.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities

xD 0x41 <secn3t@...il.com> wrote:

> Hello,
>     Your 'race condition possibly leading to root'is a myth...
> Yes thats maybe because race condition or not, it is ASLR wich will
> prevent from ANY rootshell,and Yes, it has bveen tried... You can do
> better, go right ahed ;-) I am betting you thats why it aint being ptached
> in any hurry, because obv if you read some notes about it in the committs,
> you will see they must have reproduced the said bugs, in and with, more
> than JUST bzexe even... but anyhow, your PoC is bs.

I think you misunderstood, he's not talking about memory corruption, his
attack sounds like a legitimate filesystem race. I'll try to explain, the
bzexe utility compresses executables and then decompresses them at runtime
by prepending a decompression stub.

His attack is against the stub, which is a bourne shell script. It basically
does this:

    1. Safely decompress the original executable inside /tmp using tempfile.
    2. Create a hardlink to the decompressed executable with the same name
of the original input (this is a trick to maintain argv[0], which is not as
easy in bourne as it is in modern shells).
    3. Execute the hardlink with the requested parameters.

His attack is against stage 2, he points out that although it is safe to use
the link() system call in /tmp, the ln(1) utility does some convenience
processing if you pass it a directory name.

So, the attack scenario would be that root executed a bzexe compressed
executable called foo, and then he creates the directory /tmp/foo, and makes
it 777.

ln actually succeeds, but created /tmp/foo/foo instead. The attacker still
owns /tmp/foo, so he quickly rename()s it and replaces /tmp/foo with his
exploit.

Now root executes it, and gives him a root shell.

Vladz suggests using -F, which will solve this problem by telling ln to use
the directory name instead. This will work nicely.

> Make it then ill
> believe it, ask others, you wont beat aslr on even vanilla,. So, stop
> complaining you did not get into patch- halll of flame.. it was not really
> going to be ever exploited, or you would surely not be the one posting
> this ;) Anyhow, nice try but no banana. xd

I think it's quite a nice example, and a nice simple solution. Imagine a
system where crond executes a bzexe utility at regular intervals, Vladz'
attack will eventually succeed.

Tavis.

> 
> 
> On 24 October 2011 05:55, vladz <vladz@...zero.fr> wrote:
> 
> > On Fri, Oct 21, 2011 at 07:59:59PM -0400, bugs@....dhs.org wrote:
> > > bzexe utility:
> > >
> > > /bin/bzexe:tmp=gz$$ /bin/bzexe:rm -f zfoo[12]$$
> >
> > I reported this one several months ago (in some conditions it could lead
> > to a root exploit) and provided an easy solution, but no updates:
> >
> >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632862
> >
> > -- http://vladz.devzero.fr PGP key 8F7E2D3C from pgp.mit.edu
> >
> > _______________________________________________ Full-Disclosure - We
> > believe in it. Charter:
> > http://lists.grok.org.uk/full-disclosure-charter.html Hosted and
> > sponsored by Secunia - http://secunia.com/
> >
> 
> 


-- 
-------------------------------------
taviso@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists