[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAnPYQ4OJfyD9CWXVihRBDMkXU44edzWSm9mUUn5S7-tDb0hGg@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
