[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170613212704.GA16726@openwall.com>
Date: Tue, 13 Jun 2017 23:27:04 +0200
From: Solar Designer <solar@...nwall.com>
To: Matt Brown <matt@...tt.com>
Cc: kernel-hardening@...ts.openwall.com
Subject: Re: Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM
Matt,
I removed most CC's like before, as I don't want my voice on this to be
too loud.
On Thu, Jun 08, 2017 at 11:50:32PM -0400, Matt Brown wrote:
> On 06/08/2017 10:38 PM, Kees Cook wrote:
> >On Wed, Jun 7, 2017 at 8:43 PM, Matt Brown <matt@...tt.com> wrote:
> >>* Issues:
> >> * Can be bypassed by interpreted languages such as python. You can run
> >> malicious code by doing: python -c 'evil code'
> >
> >What's the recommendation for people interested in using TPE but
> >having interpreters installed?
>
> If you don't need a given interpreter installed, uninstall it. While
> this is common sense system hardening it especially would make a
> difference under the TPE threat model.
>
> I don't have a knock down answer for this. Interpreters are a hard
> problem for TPE.
Interpreters are only a tip of the iceberg.
With TPE, every program invocation becomes similar to a SUID/SGID one as
it relates to TPE's newly introduced security barrier. However, the
dynamic linker and libc have no idea of this, and will happily grant
arbitrary code execution in context of those programs via LD_PRELOAD and
such. Even if this is somehow dealt with (how would you do that in the
kernel alone? filter typical env var names? it quickly becomes way too
hackish and blacklistish, thus imperfect), then there's still:
I think many, and maybe most, binaries on a system will contain buffer
overflows and such that also allow for arbitrary code execution. Those
programs were not written as carefully as SUID/SGID ones are supposed to
be. They don't treat their input and environment as untrusted.
Closer to the topic of interpreters, there's also this old trick:
$ strace -e execve /lib/ld-linux.so.2 /bin/uname -ms
execve("/lib/ld-linux.so.2", ["/lib/ld-linux.so.2", "/bin/uname", "-ms"], [/* 28 vars */]) = 0
Linux i686
+++ exited with 0 +++
As you can see, the only execve(2) is of the dynamic linker. Will /lib
or/and /lib64 be among trusted paths in a typical setup? Well, maybe
not, although not including them will break ldd(1) on the more security
conscious distros, where it uses a similar trick of invoking the dynamic
linker explicitly (rather than the historical unsafe way of invoking the
binary being ldd'ed with some env vars set to tell its dynamic linker to
do the magic rather than proceed to execute the program).
But this last one is relatively minor. The real big issue is that TPE
is either inherently fairly easily bypassable (and should be documented
as such) via many of the installed programs (by far not just explicit
interpreters, but also any programs containing "weird machines", which
is probably most non-trivial programs out there, and some trivial ones),
or it relies on all programs in the trusted paths being written as if
they were SUID/SGID (unrealistic for non-trivial systems).
Just so that you know what you're getting into, and so that you don't
mislead your users.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
