Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 14 Jun 2017 01:53:56 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Solar Designer <solar@...nwall.com>, 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


On 13/06/2017 23:27, Solar Designer wrote:
> 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:

What about using the AT_SECURE auxv (cf. security_bprm_secureexec)?

> 
> I think many, and maybe most, binaries on a system will contain buffer
> overflows and such that also allow for arbitrary code execution.  Those

Enforcing W^X (cf. tpe.memory xattr) mitigate this threat.

> programs were not written as carefully as SUID/SGID ones are supposed to
> be.  They don't treat their input and environment as untrusted.

Sure, but perfect is the enemy of good. Having a kernel enforcing TPE is
a good argument to convince userland to be hardened against untrusted
input. ;) For example, thanks to PaX, the Gentoo Hardened community
patched a lot of userland programs to make them compatible with PIE and
other security features.

> 
> 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).

Right, this is the most complex part, but we should start somewhere. :)
This kind of machine can not be constrain by the kernel, only by the
programs themselves. We need them to honor the AT_SECURE.

> 
> Just so that you know what you're getting into, and so that you don't
> mislead your users.
> 
> Alexander
> 



Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

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.