[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Symlink vulnerabilities
- To: full-disclosure@xxxxxxxxxxxxxxxxx
- Subject: Re: [Full-disclosure] Symlink vulnerabilities
- From: Benjamin Renaut <benml@xxxxxxxxxx>
- Date: Thu, 27 Oct 2011 17:01:30 +0200
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@xxxxxxxxxx> 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@xxxxxxxxxxx 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@xxxxxxxxxxxxx
>>>>>> <mailto:taviso@xxxxxxxxxxxxx>> wrote:
>>>>>>
>>>>>> xD 0x41<secn3t@xxxxxxxxx<mailto:secn3t@xxxxxxxxx>> 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@xxxxxxxxxx
>>>>>> <mailto:vladz@xxxxxxxxxx>> wrote:
>>>>>> >
>>>>>> > > On Fri, Oct 21, 2011 at 07:59:59PM -0400, bugs@xxxxxxxxxxx
>>>>>> <mailto:bugs@xxxxxxxxxxx> 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@xxxxxxxxxxxxx<mailto:taviso@xxxxxxxxxxxxx> | 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/