Date: Tue, 25 Oct 2011 20:42:38 -0400 (EDT)
From: bugs@....dhs.org
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities


Aw, Even if you loop and copy a binary continuously into that directory
say bash is bzexe'd.

and our exploit does the following

#!/bin/sh
chmod 777 /etc/shadow

You'll get,

kemical:~# bzexe bash
  bash:     2.214:1,  3.614 bits/byte, 54.83% saved, 700492 in, 316442 out.
kemical:~# ./bash
./bash: line 14: /tmp/bash: is a directory
/bin/rm: cannot remove `/tmp/bash': Is a directory

kemical:~# ls -l /etc/shadow
-rw-r----- 1 root shadow 1174 2010-12-07 16:49 /etc/shadow


+ /bin/rm -f /tmp/gztmpYCf11e /tmp/bash
/bin/rm: cannot remove `/tmp/bash': Is a directory



> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Race condition != Memory corruption...
>
> (and therefore ASLR has NOTHING to do with it...)
>
> http://i.imgur.com/l1l3o.gif <= me after reading this.
>
> On 10/25/2011 06:56 PM, xD 0x41 wrote:
>> 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.
>>
>> You can make it bypass Aslr ?
>> This is what im talking about tavis, not the well known ln and other
>> bugs you have pleasured us all with :)
>> THIS one, cannot be won.
>> proove it, it is a shitty poc, i cannot get passed the break when it
>> symlinks across using ln, it triggers something, and shuts whatever
>> down..
>> Your audit and kcopes audit bugs, work alittle differently..
>> This PoC is a *fail* Tavis, you would otherwise have made it into a real
>> poc that actually spawns root , yes even in cron if what your saying is
>> right , no?
>> Im saying, Kernel will shut your PoC down, your saying it wont.
>> Proove me wrong , coz sofar, many have tried and many have failed.
>> it does not even need be disclosed, i dont mind.
>> i would be happy thelp fix a bug within the kernel but, we both know
>> this is not within kernel land,it is a bug in another area,
>> It still must bypass atleast ASLR on vanilla to be called a real poc,and
>> be treated as such by the secteam of Ubuntu and debian, of wich, they
>> dont seem to be in any hurry atall about this one, where, your ones, and
>> kcopes, they were VERY prompt to jump on.
>> i believe many have recreated it, but simply cannnot get it to spawn a
>> stable enough root shell.
>> Your the brains in bash, i wont deny you this, but i do not se this one
>> working Tavis :s
>> Please, by all means, proove it and Vladz name is clear. Otherwise to me
>> is just another exposed failed poc wich is screaming for ubuntu devteam
>> to give a crap :s.
>> My outlook is bleak, yes, but i was part of one of such teams years ago,
>> altho, i wont go into that now, it is not even part of this OS, so, I do
>> know how secteams somewhat work, they prioritise things.
>> if a bug is being used like crazy to exploit, they will simply implant
>> some new binarys, along with theyre kernel..and possibly update bzexe
>> and bunzip etc, all of wich have had many flaws, i just dont think a
>> race condition can be won in this case.
>> Thats from actual hard code exploits not running because of aslr, on the
>> simplest of setups even.
>> Its already out, this infos, so, if you think it also leads to root,
>> then i would expect YOU of all people to be alot more proactive about
>> it.
>> Your not though.
>> I appreciate the time you have taken but, i believe you wont win this
>> race :).
>> Have a nice day.
>> xd
>>
>>
>> On 25 October 2011 21:06, Tavis Ormandy <taviso@...xchg8b.com
>> <mailto:taviso@...xchg8b.com>> wrote:
>>
>>     xD 0x41 <secn3t@...il.com <mailto: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
>>     <mailto:vladz@...zero.fr>> wrote:
>>     >
>>     > > On Fri, Oct 21, 2011 at 07:59:59PM -0400, bugs@....dhs.org
>>     <mailto: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
>>     <http://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 <mailto: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/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iF4EAREIAAYFAk6nSXkACgkQt/95fIeU+XYT2wD8CnpWw+xUx3eGSnxCWv7LVk1a
> kZgZJGQH1OdZR9uV4K8A/1BsiZ+gaDjE4Wz5L+BT56AU9XKvb4txjxVTMA8+GTna
> =AD/5
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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