Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ