lkml.org 
[lkml]   [2004]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Umbrella-devel] Re: Getting full path from dentry in LSM hooks
From Valdis.Kletnieks@vt ...
DateFri, 03 Sep 2004 16:39:01 -0400
On Fri, 03 Sep 2004 22:05:03 +0200, =?UTF-8?B?S3Jpc3RpYW4gU8O4cmVuc2Vu?= said:

> Also simple bufferoverflows in suid-root programs may be avoided. The
> simple way would to set the restriction "no fork", and thus if an
> attacker tries to fork a (root) shell, this would be denied.

All this does is stop fork(). I'm not sure, but most shellcodes I've seen
don't bother forking, they just execve() a shell....
It doesn't stop a buffer overflow that does this:

f1 = open("/bin/bash");
f2 = open("/tmp/bash", O_CREAT);
while ((bytes = read(f1,buffer,sizeof(buffer))) > 0)
write(f2,buffer,bytes);
fchmod(f2,4775);
close(f1); close(f2);
Papering over *that* one by restricting fchmod just means the exploit needs to
append a line to /etc/passwd, or create a trojan inetd.conf or crontab entry,
or any of the other myriad ways a program can leave a backdoor (there's a
*reason* SELinux ends up with all those rules - this isn't an easy task)...

Remember - just papering over the fact that most shellcodes just execve() a
shell doesn't fix the fundemental problem, which is that the attacker is able
to run code of his choosing as root.

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2010