lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <4EA9761E.4060300@tokidev.fr> Date: Thu, 27 Oct 2011 17:17:50 +0200 From: Benjamin Renaut <benml@...idev.fr> To: bugs@....dhs.org Cc: full-disclosure@...ts.grok.org.uk Subject: Re: Symlink vulnerabilities Thanks ! Mine is definitely not more refined, it simply does the same ;-) the only advantage I see is that it's written in C and will probably run faster - giving it more chances of success. On 27/10/11 17:12, bugs@....dhs.org wrote: > my notes/exploit: > > http://www.downspout.org/?q=node/7 > > I am sure yours is more refined than mine. > >> I just wrote a quick PoC for this (warning: didn't test the code a lot): >> >> http://pastebin.com/FaaEsXRW >> >> (compile that with -O3). >> successfully tried it on my machine (Debian stable, amd64, high-end >> laptop). >> It probably has more chances of success on low-end hardware, or if the >> system is busy. >> >> If you really really want it to work the first time, bzexe a binary >> (say, ls) and then open the resulting file. >> Increment the value of the "skip" variable at the top and add: >> >> sleep 1 >> >> right after the "/bin/ln $tmpfile..." line. This will slow down the >> bzexe shell script so the flaw is more visible. >> >> The example shellcode in the PoC will simply execute "id" and write the >> output into /tmp/stdout.bzexe_poc. >> >> Note that this'll work not only with root: you can execute something >> with the rights of any user launching a bzexe-d binary (as long as you >> know what they're gonna run beforehand). >> >> Regards, >> Benjamin Renaut. >> >> On 27/10/11 16:08, Benjamin Renaut wrote: >>> Imagine the following scenario: >>> >>> - You create /tmp/<prog name> (a directory) >>> - Root is launching a bzexe-d binary (<prog name>). >>> - The ln done by bzexe results in the link being created inside >>> /tmp/<prog name> (your directory), as explained by Vlad. >>> - Before the bzexe shell script executes /tmp/<prog name>, you remove >>> your directory (/tmp/<prog name>) and replace it by an evil shell >>> script. >>> - The bzexe shell code executes *your* shell script, with root rights. >>> >>> => So *yes*, this seems exploitable, given the following requirement: >>> root has to execute a bzexe binary and you have to know it beforehand. >>> >>> The race condition if a little hard to exploit but it's doable. >>> >>> As for a POC, just add some sleep commands inside the bzexe shell script >>> and it becomes easy to prove. >>> >>> On 27/10/11 15:43, xD 0x41 wrote: >>>> Vlad, >>>> I wont repeat myself, again, your PoC will NOT work. >>>> it will NOT get root anything! >>>> please, understand it, and maybe, make a working poc, then see why... >>>> It was shown clearly by 2 people or more that, it cannot work. >>>> If you can do better, and, sure, do what you said wich is exact area >>>> where it wont listen tho... wich is here: >>>> >>>> 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"). >>>> >>>> You try to change and fiddle here, it would need alot better than just >>>> the current shell scripting, and, even then, i dnt think it would win >>>> the race conditiobn. >>>> I have made a poc, i know atleast 2 others have, and, I guess those >>>> people have already shown where it goes wrong for them and, it is no >>>> different, because, for whatever reason, if you say it is not aslr, >>>> thats fine... but, i am just saying what my opinion is. >>>> You can dream all you want about this being so leet but, dude, they >>>> would have bothered to patch it, if indeed it led to anything *root* >>>> or pwnage, wich is when they suually act. >>>> So, I know for fact, there is easier methods than this to be had, and >>>> telling you, am very experinced with these scripts, and this >>>> particular one, i wanted to use, ofcourse, to root some kernels! Hell, >>>> i am a blackhat...so, i wanted to remake but, nothing, and when >>>> exchanged notes on it, I got nothing but told, aslr/memory will shut >>>> it down, etc etc.. but, i stfu and kept writing my poc, then, when i >>>> thought it was perfect, it would not allow me to occupy that space, >>>> maybe if i could be bothered to occupy the EIP or, overwrite it >>>> somehow, then i would perhaps bother for race, but seriusly in the >>>> form your saying, well, hey, kets just tar anything, and, rely on the >>>> internals to fail...surely this would never give us root... >>>> >>>> >>>> as i said.. you dont need to even look as far as you are, but, this is >>>> a flawed and, sorry but, it is prroven to fail. >>>> if it were any decent, like kcopes sh scripts usually are, then, it >>>> would be PATHCED :) >>>> Sorry, no banana i said :) >>>> I mean it. >>>> you will NOT make any PoC here in bash script. >>>> Sorry, but, get out of those delusional state, and, skip to real >>>> world, it is 2011, and it is vanilllllla :) >>>> anyhow, have a good day but, please, i have said and prooven whatever >>>> i wanted, so, i dont need any more tech talk, it is a failed poc, when >>>> u will understand even how secteams like ubuntu work, then maybe, you >>>> will see that, it is indeed flawed and, thus de prioritised and face >>>> it, i know many hax0rs and, they never once mentioned it, and believe >>>> me, they sfrape these lists with 3x finetooth combs :P >>>> This is NOT HAPPENIN! >>>> Ok, that is enough now, have a nice day, and, no, i dont want any >>>> replys saying how "yes yes but it can thru this and that..." , coz, IT >>>> CANT so please, have a nice day, and, go read up on git or >>>> sumthin...do sumthin useful, your wasting time pushing on a dead pioc. >>>> either fkn make it properly, or stfu and simply accept it cannot b >>>> done, now, i know howmany lines it took me, and, if you cannot make >>>> the failure poc wich you outlined, then, id be dissapintedm, as >>>> someone alredy has done, exactly what you did, and, showed it >>>> executing, and FAILING. >>>> That was end of it for the whole list i believe. >>>> A poc, wich was perfectly coded to meet your standards, and, it failed >>>> dude. you cannot just chmod any file and make it *suid*... seriously, >>>> whatever ebooks your reading (GNY??) get off them, theyre bad for your >>>> health like nicotine is to me :) >>>> ciao baby >>>> xdab >>>> >>>> >>>> >>>> >>>> On 27 October 2011 06:31, vladz<vladz@...zero.fr> 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@....dhs.org 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@...xchg8b.com >>>>>>>> <mailto:taviso@...xchg8b.com>> wrote: >>>>>>>> >>>>>>>> xD 0x41<secn3t@...il.com<mailto: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 >>>>>>>> <mailto:vladz@...zero.fr>> wrote: >>>>>>>> > >>>>>>>> > > On Fri, Oct 21, 2011 at 07:59:59PM -0400, >>>>>>>> bugs@....dhs.org >>>>>>>> <mailto: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 >>>>>>>> <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@...xchg8b.com<mailto: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/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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/ >>> _______________________________________________ >>> 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/
Powered by blists - more mailing lists