Message-ID: <a95c5835b4ad2348ae8819025ad9239f.squirrel@fbi.dhs.org>
Date: Thu, 27 Oct 2011 11:12:47 -0400 (EDT)
From: bugs@....dhs.org
To: "Benjamin Renaut" <benml@...idev.fr>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities


my notes/exploit:

http://www.downspout.org/?q=node/7

I am sure yours is more refined than mine.

> I just wrote a quick PoC for this (warning: didn't test the code a lot):
>
> http://pastebin.com/FaaEsXRW
>
> (compile that with -O3).
> successfully tried it on my machine (Debian stable, amd64, high-end
> laptop).
> It probably has more chances of success on low-end hardware, or if the
> system is busy.
>
> If you really really want it to work the first time, bzexe a binary
> (say, ls) and then open the resulting file.
> Increment the value of the "skip" variable at the top and add:
>
> sleep 1
>
> right after the "/bin/ln $tmpfile..." line. This will slow down the
> bzexe shell script so the flaw is more visible.
>
> The example shellcode in the PoC will simply execute "id" and write the
> output into /tmp/stdout.bzexe_poc.
>
> Note that this'll work not only with root: you can execute something
> with the rights of any user launching a bzexe-d binary (as long as you
> know what they're gonna run beforehand).
>
> Regards,
> Benjamin Renaut.
>
> On 27/10/11 16:08, Benjamin Renaut wrote:
>> Imagine the following scenario:
>>
>> - You create /tmp/<prog name>  (a directory)
>> - Root is launching a bzexe-d binary (<prog name>).
>> - The ln done by bzexe results in the link being created inside
>> /tmp/<prog name>  (your directory), as explained by Vlad.
>> - Before the bzexe shell script executes /tmp/<prog name>, you remove
>> your directory (/tmp/<prog name>) and replace it by an evil shell
>> script.
>> - The bzexe shell code executes *your* shell script, with root rights.
>>
>> =>  So *yes*, this seems exploitable, given the following requirement:
>> root has to execute a bzexe binary and you have to know it beforehand.
>>
>> The race condition if a little hard to exploit but it's doable.
>>
>> As for a POC, just add some sleep commands inside the bzexe shell script
>> and it becomes easy to prove.
>>
>> On 27/10/11 15:43, xD 0x41 wrote:
>>> Vlad,
>>>       I wont repeat myself, again, your PoC will NOT work.
>>> it will NOT get root anything!
>>> please, understand it, and maybe, make a working poc, then see why...
>>> It was shown clearly by 2 people or more that, it cannot work.
>>> If you can do better, and, sure, do what you said wich is exact area
>>> where it wont listen tho... wich is here:
>>>
>>> This means that right after the "ln" command AND before "/tmp/dd" is
>>> launched, the user can replace the directory "/tmp/dd" by a shell
>>> script
>>> with the same name ("/tmp/dd").
>>>
>>> You try to change and fiddle here, it would need alot better than just
>>> the current shell scripting, and, even then, i dnt think it would win
>>> the race conditiobn.
>>> I have made a poc, i know atleast 2 others have, and, I guess those
>>> people have already shown where it goes wrong for them and, it is no
>>> different, because, for whatever reason, if you say it is not aslr,
>>> thats fine... but, i am just saying what my opinion is.
>>> You can dream all you want about this being so leet but, dude, they
>>> would have bothered to patch it, if indeed it led to anything *root*
>>> or pwnage, wich is when they suually act.
>>> So, I know for fact, there is easier methods than this to be had, and
>>> telling you, am very experinced with these scripts, and this
>>> particular one, i wanted to use, ofcourse, to root some kernels! Hell,
>>> i am a blackhat...so, i wanted to remake but, nothing, and when
>>> exchanged notes on it, I got nothing but told, aslr/memory will shut
>>> it down, etc etc..  but, i stfu and kept writing my poc, then, when i
>>> thought it was perfect, it would not allow me to occupy that space,
>>> maybe if i could be bothered to occupy the EIP or, overwrite it
>>> somehow, then i would perhaps bother for race, but seriusly in the
>>> form your saying, well, hey, kets just tar anything, and, rely on the
>>> internals to fail...surely this would never give us root...
>>>
>>>
>>> as i said.. you dont need to even look as far as you are, but, this is
>>> a flawed and, sorry but, it is prroven to fail.
>>> if it were any decent, like kcopes sh scripts usually are, then, it
>>> would be PATHCED :)
>>> Sorry, no banana i said :)
>>> I mean it.
>>> you will NOT make any PoC here in bash script.
>>> Sorry, but, get out of those delusional state, and, skip to real
>>> world, it is 2011, and it is vanilllllla :)
>>> anyhow, have a good day but, please, i have said and prooven whatever
>>> i wanted, so, i dont need any more tech talk, it is a failed poc, when
>>> u will understand even how secteams like ubuntu work, then maybe, you
>>> will see that, it is indeed flawed and, thus de prioritised and face
>>> it, i know many hax0rs and, they never once mentioned it, and believe
>>> me, they sfrape these lists with 3x finetooth combs :P
>>> This is NOT HAPPENIN!
>>> Ok, that is enough now, have a nice day, and, no, i dont want any
>>> replys saying how "yes yes but it can thru this and that..." , coz, IT
>>> CANT so please, have a nice day, and, go read up on git or
>>> sumthin...do sumthin useful, your wasting time pushing on a dead pioc.
>>> either fkn make it properly, or stfu and simply accept it cannot b
>>> done, now, i know howmany lines it took me, and, if you cannot make
>>> the failure poc wich you outlined, then, id be dissapintedm, as
>>> someone alredy has done, exactly what you did, and, showed it
>>> executing, and FAILING.
>>> That was end of it for the whole list i believe.
>>> A poc, wich was perfectly coded to meet your standards, and, it failed
>>> dude. you cannot just chmod any file and make it *suid*... seriously,
>>> whatever ebooks your reading (GNY??) get off them, theyre bad for your
>>> health like nicotine is to me :)
>>> ciao baby
>>> xdab
>>>
>>>
>>>
>>>
>>> On 27 October 2011 06:31, vladz<vladz@...zero.fr>   wrote:
>>>> This vulnerability is trivial and I don't even know why it is making
>>>> so
>>>> much noises as bzexe is almost never used and the exploit would only
>>>> work under certain circumstances.  It quoted it because it was an
>>>> example of insecure uses of "/tmp", thats all!
>>>>
>>>> Note for "xD 0x41":  before you say something about "ASLR", know that
>>>> it
>>>> has nothing to see with it.
>>>>
>>>> I will explain it shortly (even if Tavis was very clear), and hope
>>>> this
>>>> will end this conversation! lol
>>>>
>>>> Imagine the "dd" command has been compressed by root using bzexe:
>>>>
>>>>    # bzexe /bin/dd
>>>>      /bin/dd:  1.996:1,  4.008 bits/byte, 49.90% saved, 49168 in,
>>>> 24635 out.
>>>>
>>>>    # ls -l /bin/dd*
>>>>    -rwxr-xr-x 1 root root 25286 26 oct.  20:38 /bin/dd
>>>>    -rwxr-xr-x 1 root root 49168 28 avril  2010 /bin/dd~
>>>>
>>>>    # cat -n /bin/dd | head -15
>>>>         1        #!/bin/sh
>>>>        [...]
>>>>        10          prog="`echo $0 | /bin/sed 's|^.*/||'`"
>>>>        11          if /bin/ln $tmpfile "/tmp/$prog" 2>/dev/null; then
>>>>        12            trap '/bin/rm -f $tmpfile "/tmp/$prog"; exit
>>>> $res' 0
>>>>        13            (/bin/sleep 5; /bin/rm -f $tmpfile "/tmp/$prog")
>>>> 2>/dev/null&
>>>>        14            /tmp/"$prog" ${1+"$@"}; res=$?
>>>>        [...]
>>>>
>>>> If a user creates a directory "/tmp/dd", look what happens when root
>>>> calls "dd":
>>>>
>>>>    # bash -x /bin/dd
>>>>    [...]
>>>>    + /usr/bin/tail -n +23 /bin/dd
>>>>    + umask 0022
>>>>    + /bin/chmod 700 /tmp/gztmpIfsTrk
>>>>    ++ /bin/sed 's|^.*/||'
>>>>    ++ echo /bin/dd
>>>>    + prog=dd
>>>>    + /bin/ln /tmp/gztmpIfsTrk /tmp/dd<<   ln succeeded!
>>>>    + trap '/bin/rm -f $tmpfile "/tmp/$prog"; exit $res' 0
>>>>    + /tmp/dd<<   /tmp/dd is launched!
>>>>    /bin/dd: line 14: /tmp/dd: is a directory
>>>>
>>>> This means that right after the "ln" command AND before "/tmp/dd" is
>>>> launched, the user can replace the directory "/tmp/dd" by a shell
>>>> script
>>>> with the same name ("/tmp/dd").
>>>>
>>>> Is this clear enough?
>>>>
>>>> Cheers,
>>>> vladz.
>>>> --
>>>> http://vladz.devzero.fr
>>>> PGP key 8F7E2D3C from pgp.mit.edu
>>>>
>>>>
>>>> On Tue, Oct 25, 2011 at 08:42:38PM -0400, bugs@....dhs.org wrote:
>>>>> 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/
>>>> _______________________________________________
>>>> 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/
>> _______________________________________________
>> 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/
>


_______________________________________________
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