Message-ID: <4EA965C0.5090406@tokidev.fr>
Date: Thu, 27 Oct 2011 16:08:00 +0200
From: Benjamin Renaut <benml@...idev.fr>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities

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/

Powered by blists - more mailing lists