Date: Tue, 25 Oct 2011 08:56:10 -0400 (EDT)
From: bugs@....dhs.org
To: "Tavis Ormandy" <taviso@...xchg8b.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities

I think it was ln -T ?


> 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/
>


_______________________________________________
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