Message-ID: <425CF2F2.29033.12B70A79@localhost>
Date: Wed Apr 13 10:23:18 2005
From: pageexec at freemail.hu (pageexec@...email.hu)
Subject: linux bugs (survival stories)? 

> Now this, unlike the /lib/ld-linux.so hack, is a still-existing issue.

it's not just 'an issue', it makes the whole exercise pointless,
that's The Issue. that is, if someone has the capability to write
to a noexec mount (and only noexec mounts of course, else this
whole scenario is irrelevant), then he can easily circumvent the
current linux noexec handling - what's the point then?

> However, this is getting rather far afield, because:
> 
> 1) This is quite arguably a "design decision" rather than an outright bug.

depends on what the original 'design' was. if it wanted to close
the ld-linux.so method, then it's fine because it does that. if it
wanted to actually enforce the noexec mount option then it's not
fine because it doesn't do that. you and many other people have
been selling this feature as the latter, not the former, whereas
the current mount manpage clearly states that it's the former only
(inasmuch 'direct execution' means 'mmap' there, the manpage could
be more clear on this so that people don't mistake it for proper
noexec enforcement).

> 2) Whether it's a bug or not, it only impacts userspace security - and we

not quite, because exploiting a kernel bug requires, well, an
exploit and if you already have control over runtime code generation
(PaX) then the only other intrusion vector will be through the
filesystem, that's where the noexec mount option can play a role
in prevention.

obviously it's a very coarse grained control mechanism, but i can
imagine that in some situations it's useful (else the whole noexec
option wouldn't need to exist ;-), provided it actually does its
advertized job.

> started off discussing protecting the kernel itself from kernel bugs....

ok, let's talk about it a bit then as well. first, the exact topic
was about the value of defense mechanisms against kernel bugs, the
OP didn't specify whether he was interested in the userland or the
kernel impact of them (the answers are a bit different).

let's see the userland impact: since in the UNIX model the kernel
itself is considered the trusted computing base (actually, it's
more than that, but let's no diverge), any (memory corruption) bug
in there can naturally compromise at least the userland privilege
info, so escalating userland privileges is a given and it's very
hard to directly protect against that, i'd say 'impossible' for
practical purposes (note 'directly' here, by that i mean "allow the
bug to manifest (say an overflow) but still prevent exploitation").

on the other hand we can try to prevent exploitation in indirect
ways, but their actual value/feasibility depends on the circumstances,
they're not generic. one such approach is to enforce W^X over the
filesystem (in addition to doing it on process memory) for a given
(otherwise unprivileged) user, then you can at least prevent the
execution of machine code (it's another question if that's enough
to prevent exploitation, it again depends on the circumstances).
obviously if we have to allow untrusted users to generate (and run)
executable code on the machine (which i guess is the more common
real life scenario), then we lose, we can at most detect a
successful intrusion after the fact.

onto the kernel impact of kernel bugs: just like for the userland
case, the kernel's (writable) data cannot be protected reliably
(and efficiently), so if an intrusion can achieve its objectives by
mere data modification, then we lose. on the other hand it's possible
to protect the kernel's code, that is, we can prevent direct machine
code execution in the kernel (an incomplete but already useful
example would be PaX's KERNEXEC, which contrary to your statement
does not address userspace bugs but those of the kernel).

> (Not that I'm adverse to a thread on "what the kernel could do to harden
> userspace" - but somebody needs to change the Subject: line if we go that way...)

hey, it's not like i started to divert it ;-), it's just that you
said that "The last really big "trivial" issue with bypassing
noexec on mounted filesystems was closed" whereas it's simply not
true, better not spread this.

Powered by blists - more mailing lists