Re: [Full-disclosure] 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@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/



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/



Relevant Pages

  • Re: [Full-disclosure] Symlink vulnerabilities
    ... If you really really want it to work the first time, bzexe a binary ... The example shellcode in the PoC will simply execute "id" and write the ... The bzexe shell code executes *your* shell script, with root rights. ...
    (Full-Disclosure)
  • Re: [Full-disclosure] Symlink vulnerabilities
    ... If you really really want it to work the first time, bzexe a binary ... The example shellcode in the PoC will simply execute "id" and write the ... The bzexe shell code executes *your* shell script, with root rights. ... As for a POC, just add some sleep commands inside the bzexe shell script ...
    (Full-Disclosure)
  • Re: [Full-disclosure] Symlink vulnerabilities
    ... - The bzexe shell code executes *your* shell script, with root rights. ... I wont repeat myself, again, your PoC will NOT work. ... Now root executes it, and gives him a root shell. ...
    (Full-Disclosure)
  • Re: [Full-disclosure] Symlink vulnerabilities
    ... I just wrote a quick PoC for this: ... If you really really want it to work the first time, bzexe a binary ... The example shellcode in the PoC will simply execute "id" and write the ... - The bzexe shell code executes *your* shell script, with root rights. ...
    (Full-Disclosure)
  • Re: [Full-disclosure] Symlink vulnerabilities
    ... Imagine the "dd" command has been compressed by root using bzexe: ... Now root executes it, and gives him a root shell. ... Charter: http://lists.grok.org.uk/full-disclosure-charter.html ...
    (Full-Disclosure)