[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Symlink vulnerabilities
- To: vladz <vladz@xxxxxxxxxx>
- Subject: Re: [Full-disclosure] Symlink vulnerabilities
- From: xD 0x41 <secn3t@xxxxxxxxx>
- Date: Fri, 28 Oct 2011 00:47:44 +1100
BTE , exploits launched and ran from root, or even have anything todo
with being near root dir, is not really what id call a userland poc.
So, stop convincing me that you can exploit root, and look back a few
examples, wich shows, your cmd as user, failing... and, if you say it
cannot be any clearer, then simple POC it and shut ME up, but until
now, im waiting for u and Tavis, who has seemed to back right out now
of this...and, i have seen nothing but people actually saying they
have tried, and failed.
So, if your a genius from root, let us see the genius from user now :P
you think launching from root would not do shit but, it really does, i
mean, do u see kids rooting boxes from root, to gain root, no. so,
yea, some cmds work.... maybe, im just tired, and, seen it fails, and
cbf, but.. either way, it is no poc in root dir buddy.
gnite
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/