[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25278a42-736e-0d3b-8c0a-7b2b05ed7d28@digikod.net>
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.
