-----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 <[email protected] > <mailto:[email protected]>> wrote: > > xD 0x41 <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> wrote: > > > > > On Fri, Oct 21, 2011 at 07:59:59PM -0400, [email protected] > <mailto:[email protected]> 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/ > > > > > > > > > > -- > ------------------------------------- > [email protected] <mailto:[email protected]> | 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/
