[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] Symlink vulnerabilities

-----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/