Full Disclosure mailing list archives
Re: linux bugs (survival stories)?
From: pageexec () freemail hu
Date: Wed, 13 Apr 2005 10:22:42 +0100
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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: linux bugs (survival stories)?, (continued)
- Re: linux bugs (survival stories)? Georgi Guninski (Apr 12)
- Re: linux bugs (survival stories)? dk (Apr 12)
- Re: linux bugs (survival stories)? Eduardo Tongson (Apr 12)
- Re: linux bugs (survival stories)? Valdis . Kletnieks (Apr 12)
- Re: linux bugs (survival stories)? Eduardo Tongson (Apr 12)
- Re: linux bugs (survival stories)? Joachim Schipper (Apr 12)
- Re: linux bugs (survival stories)? Valdis . Kletnieks (Apr 12)
- Re: linux bugs (survival stories)? Eduardo Tongson (Apr 13)
- Re: linux bugs (survival stories)? Valdis . Kletnieks (Apr 12)
- Re: linux bugs (survival stories)? pageexec (Apr 13)
- Re: linux bugs (survival stories)? Valdis . Kletnieks (Apr 13)
- Re: linux bugs (survival stories)? pageexec (Apr 13)
- Re: linux bugs (survival stories)? Valdis . Kletnieks (Apr 13)
- Re: linux bugs (survival stories)? pageexec (Apr 13)