Date: Fri, 19 Feb 2016 02:28:47 +0000 From: Gynvael Coldwind <gynvael@...dwind.pl> To: oss-security@...ts.openwall.com Subject: Re: Re: Address Sanitizer local root And if that fails, there's always the ASAN_SYMBOLIZER_PATH environment variable, which just makes the ASANified binary execute the executable you give it ( http://clang.llvm.org/docs/AddressSanitizer.html#symbolizing-the-reports) ;) On Fri, Feb 19, 2016 at 12:19 AM Darren Martyn < darren.martyn@...hosresearch.co.uk> wrote: > Hi List, > Figured I would add this to the thread to keep it amusing. > > Here is a fully functioning local root by clobbering /etc/ld.so.preload > instead of /etc/shadow (which breaks things spectacularly). I am using a > fairly messy "symlink spray"/"symlink carpet bombing" technique. > > Simply point it at a setuid-root binary compiled with asan and away it > goes. > > Video: https://www.youtube.com/watch?v=jhSIm3auQMk > PoC Code: https://gist.github.com/0x27/9ff2c8fb445b6ab9c94e > > Development/Testing was done on a Debian 8.3 VM that was last updated > last week. > > Now, I wonder - what can actually be done to mitigate against this, > besides "don't use ASAN in production"? > Is there something that can be done ASAN-side? > Because due to how ld.so.preload is parsed so, uh, forgivingly, all the > attacker needs to control is one line in the output file. Could it check > for symlinks before writing the log? > > Regards, > Darren. > >
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ