Re: [2.7 "thoughts"] V0.3

[Michael Jensen]

Thanks for setting me straight.  For some reason I thought that whenever a
binary was executed (even through a buffer overflow), an exec() was issued.

Don't ask what I've been smoking...





Quoting Valdis.Kletnieks@xxxxxx:

> 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)...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/