Full Disclosure mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Symlink vulnerabilities

From: bugs () fbi dhs org
Date: Tue, 25 Oct 2011 20:42:38 -0400 (EDT)

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 () cmpxchg8b com
<mailto:taviso () cmpxchg8b com>> wrote:

    xD 0x41 <secn3t () gmail com <mailto:secn3t () gmail 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 () devzero fr
    <mailto:vladz () devzero fr>> wrote:
    >
    > > On Fri, Oct 21, 2011 at 07:59:59PM -0400, bugs () fbi dhs org
    <mailto:bugs () fbi 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 () cmpxchg8b com <mailto:taviso () cmpxchg8b 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/
Previous By Date Next
Previous By Thread Next

Current thread: