lkml.org 
[lkml]   [2003]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries
viro@parcelfarce.linux.theplanet.co.uk wrote:

>On Wed, Oct 01, 2003 at 09:33:09AM -0400, Makan Pourzandi wrote:
>
>
>
>>Third, the intruder now has access to the system, he cannot execute the
>>code he brought in with himself (not signed) or he cannot bring it in
>>(c.f. above). So he needs to compile the code on the system. AFAIK, for
>>the absolute majority of servers the admins remove all compilers
>>(specially gcc) on all servers. this is for several different security
>>reasons (I don't want to get there). therefore, the above hypothesis
>>gets even more difficult to realize.
>>
>>
>
>Don't be ridiculous. It's trivial to exploit a local buffer overrun in
>one of your signed binaries and have the shellcode mmap the rest. All
>pre-built, of course.
>
>

Hi Viro,

Obviously, I failed to show that the main functionality of digsig is to
avoid the execution of __normal__ rootkits, Trojan horses and other
malicious binaries on your system.

the above was to analyze an imaginary scenario. well, you bring a new
scenario than the mmap is used from a shell code. well, in this
scenario, digsig makes it difficult for the intruder to bring his own
rootkit and run it. i mean, yes he could decide to reboot your system or
remove all your files or ..., and digsig is not going to help here, it
isn't its job either !
Back to the subject, in the first 2 points of my previous email, I tried
to show that the use of digsig make it difficult for the intruder to
bring in the malicious binaries, __then and only then__ at last
resource, to be able to use mmaps, he can choose to compile the code
locally.

Once again, the purpose here is neither to secure system against all
possible attacks nor to avoid all possible scenarios; digsig is not
going to avoid you buffer overflows or other vulnerabilities. BTW, there
are tools to avoid that to happen (c.f. Pax, Exec Shield...). the
purpose here is to make it more difficult for the intruder to abuse the
system. if there is a remote exploit in your system, the intruder can
use it. however, i believe, as i explained in first 2 points of the
previous email, digsig makes it much more difficult for the intruder to
bring in his rootkit and use it, same for the excution of Trojan horses
or backdoor programs.

On the other hand, you're right if the people begin to write these
shellcode mmaps, this is a problem that we have to solve. however, my
understanding of the state of the art on malware today is that we don't
have many of these "shellcode mmap" exploits. generally, many of the
exploits use classical rootkits which still use exec for executing their
binaries.

regards,
makan

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

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.059 / U:1.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site