Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Makan Pourzandi <Makan.Pourzandi@ericsson.ca>]

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