Date: Wed, 26 Oct 2011 10:21:46 +1100
From: xD 0x41 <secn3t@...il.com>
To: Tavis Ormandy <taviso@...xchg8b.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities

I do know, this is quite confusing,
I have reproduced this, so has another well known exploit-eer on this list,
and both failed, altho, i have been able to use actually, parts of YOUR
poc's from debian, to gain root to almost anything, but it is not so
straight forward as just the actual scenaro of the PoC, it needs some tweaks
to make it bypass some parts of secuirty.
I will try to use the same methods and make this compressed bad.bz files,and
see if i can make the poc better,
I should not be so arrogant :)
I will altho try and test this, as it states now, vendor is not patched.
I will see what happens in bash, then ill try and just add some code to
something i already have wich might be able to atleast 'lever'
the bug in bzexe, i believe the bug still exists in other compression utils,
i recall there being many ways to create enormous file sized bz2 files wich
could basically cause overflows and d0s eveytimes, those are mostlikely
patched, but if these utilitys conme shipped with our default kernel etc,
then many people should be made well aware of such a bug, so small, wich can
spawn rootshell in 2mins, every 2minutes.
It is possible, but sofar, i have had 0 success using this actual bug
itself... it just keeps sigfeaulting, i will try a couple of approachs, but,
i do not think a race condition can be won , and, would challenge anyone to
do it, it is not something wich is hard nor private, it is on a public list,
so could be fixed in 0minute of tme, possibly, the best place to post any
bug, because they are spoken about thoroughly.
I will try my best to match the scenario Vlad has pointed out, and rremake
it, but seriously i cannot see it happening. Not yet.
cheers,
xd


On 25 October 2011 21:06, Tavis Ormandy <taviso@...xchg8b.com> wrote:

> xD 0x41 <secn3t@...il.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@...zero.fr> wrote:
> >
> > > On Fri, Oct 21, 2011 at 07:59:59PM -0400, bugs@....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
> > >
> > > _______________________________________________ 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@...xchg8b.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/
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists