[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160219010730.GF9349@brightrain.aerifal.cx>
Date: Thu, 18 Feb 2016 20:07:30 -0500
From: Rich Felker <dalias@...c.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Address Sanitizer local root
On Thu, Feb 18, 2016 at 11:19:10PM +0000, Darren Martyn 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?
Fixing this whole class of bugs is trivial -- just don't process
environment vars or other invoker-controlled input when run suid. For
most things you would want to call secure_getenv (glibc) or issetugid
(BSD) to achieve this but for sanitizer libs it may make more sense to
just access the aux vector directly and check AT_SECURE and related
items.
Of course there's a lot more state that the attacker invoking a suid
binary controlls -- resource limits, open file descriptors,
controlling ttys, signal state, etc. This also needs to be dealt with.
On a more general level, the kind of diagnostic introspection the
sanitizer libs do is just unsafe in general. Once you have a
known-compromised process state, the only thing safe to do is inducing
program termination asap. Processing complex data structures is
unsafe. Unwinding is unsafe. Function calls (especially via GOT/PLT)
and even normal system calls (on i386 where the vdso syscall pointer
is stored just after the thread stack) are unsafe. For hardening
purposes you need either an inline __builtin_trap() (and hope nobody's
catching SIGILL/SIGSEGV/SIGABRT) or ideally an inline [rt_sigprocmask,
getpid, kill] syscall sequence. Analysis of the crashing process, if
desired, should be left to an external debugger, not put in the
sanitizer libs just because it's "convenient".
Rich
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.
