Re: [2.7 "thoughts"] V0.3

[Valdis . Kletnieks]

On Fri, 10 Oct 2003 16:33:09 MDT, Michael Jensen said:

> I agree that it wouldn't have any effect on buffer overflows.  It would prevent
> further abuse of the system unless the perpetrator was able to install and load
> a modified kernel.  Even if they had root access, they would be unable to
> execute backdoor binaries because they would not be signed with a trusted key. 
> This would also thwart rootkits.

Umm... let me see if I got this straight...  They already exploited the system once
to get in originally, and you think that the same method that didn't stop them
from executing code to get in will also stop them from exploiting further?

All they need to do is park their code-to-execute in a file *anywhere* on the box,
and then invoke any of the numerous programs that have local buffer overflows,
and then use that program and an overflow sled to act as a poor-man's replacement
for /lib/ld-linux.

Hmm.. /bin/ls segfaults under some overflow conditions?  Just set up the
conditions, run /bin/ls, get the signed binary to run, and use it to load your
code. Game over. /bin/ls isn't exploitable?  Wander over to packetstorm and
pick and choose a ready-made exploit for lots of other stuff..

The basic problem here is that you're assuming that "the code loaded by exec()"
is trusted, therefor the code actually executed is trusted.  Given that most modern
processors are Von Neumann architectures rather than Harvard machines, that's a
problematic assumption.  That's why things like exec-shield or SELinux are probably
more productive directions - they are taking a different model:

exec-shield - We don't care if you're a trusted program, you're not executing off the stack.

SELinux - We don't care what binary you are, if you started in this security domain,
you're staying in it and having the restrictions enforced (yes, I know I'm simplifying
the issues with 'newrole' and the like)...

The important part is that what they *check* is actually related to the threat -
whereas checking the binary as protection against malicious code is essentially
a perverse case of a TOCTOU bug....

> Another problem that I see is that it would be quite easy to get around signed
> binaries if perl was one of those binaries.  Care would need to be taken in
> deciding what is trusted and signed.

As pointed out above, perl is just one of the problems.

> BTW - I like your suggestion of mounting everything either 'read only' or
> 'noexec', and using LSM.  I'm going to have to mess around with that.

Not to be snide or anything, if you haven't *already* investigated the existing
facilities (and found the issues with 'noexec', etc), you almost certainly haven't
thought through either the threat model or suitable defenses very thoroughly.

Attachment: pgp00001.pgp
Description: PGP signature