Date: Thu, 27 Oct 2011 17:17:50 +0200
From: Benjamin Renaut <benml@...idev.fr>
To: bugs@....dhs.org
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities

Thanks !

Mine is definitely not more refined, it simply does the same ;-)
the only advantage I see is that it's written in C and will probably run 
faster - giving it more chances of success.

On 27/10/11 17:12, bugs@....dhs.org wrote:
> 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