From: Makan Pourzandi <Makan.Pourzandi@ericsson.ca>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org,
Axelle Apvrille <Axelle.Apvrille@ericsson.ca>,
Vincent Roy <vincent.roy@ericsson.ca>,
David Gordon <davidgordonca@yahoo.ca>,
socrate@infoiasi.ro
Subject: Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries
Date: Wed, 01 Oct 2003 09:33:09 -0400 [thread overview]
Message-ID: <3F7AD795.1040001@ericsson.ca> (raw)
In-Reply-To: 20031001102631.GC398@elf.ucw.cz
Pavel Machek wrote:
>Hi!
>
>
>
>>overview
>>=======
>>
>>Instead of writing a long detailed explication, I rather give you an
>>example of how you can use it.
>>
>>
>
>Can you also add example *why* one would want to use it?
>
>
>AFAICS if I want to exec something, I can avoid exec() syscall and do
>mmaps by hand...
>
Hi,
Thank you for your feedback. This is my understanding of the situation,
if I'm wrong in my analysis, let me know.
There are different answers to this question because there are many
possible attack scenarios. I try to take the most realistic one and give
a short answer.
For the attacke described by you to be successful, one assumes that the
intruder gained access to the system, he wrote his own code on the
system (or brought it in), and compile it on the system (cannot
execute its own code as it is not signed), produced the binary to mmap
the malicious code to the memory, and run the code that call syscall
mmap.
First digsig can help to avoid the access to the system by the intruder.
as it aborts the execution of malicious code which often leads to a root
access for the intruder.
Second, digsig can avoid the execution of the binary that allows to
bring in the code or other malicious binaries. AFAIK, the intruders
generally use their own binary to download malicious code. This is
because in hardened systems, the use of ftp ot other alike binaries,
(when these binaries are not completely removed from the system for
security reasons) is closely monitored and controled through firewalling
rules. Even in simple desktops, it is rather easy to control the use of
ftp and alike to track down the intrusion source. therefore, the
intruder needs to run his own binary to download the root kit which is
avoided by the use of digsig.
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.
Last, but I believe the most important, the level of difficulty of
execution of such an attack is much higher than the average knowledge
level of many script kiddies. The absolute majority of attackers have
little or absolutely not any knowledge of the operating systems in
general and linux in particular, let aside the knowledge of writing a C
program, calling mmaps in that progam and run the malicious code to gain
access as root, then remove the module to execute a classical attack.
There is no such thing as 100% secure system, digsig increases the level
of security of the system as it just makes it much more difficult for
the intruder to succeed in his/her attack.
regards,
makan
-------------------------------------------------------
Makan Pourzandi,
Ericsson Research Canada
*This email does not represent or express the opinions of
Ericsson Inc.
-------------------------------------------------------
next prev parent reply other threads:[~2003-10-01 13:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-25 19:19 [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries Makan Pourzandi
2003-10-01 10:26 ` Pavel Machek
2003-10-01 13:33 ` Makan Pourzandi [this message]
2003-10-01 14:17 ` viro
2003-10-01 18:14 ` Makan Pourzandi
2003-10-01 18:24 ` viro
2003-10-01 21:51 ` Willy Tarreau
2003-10-01 21:55 ` Radu Filip
2003-10-01 22:05 ` Pavel Machek
2003-10-01 23:36 ` Larry McVoy
2003-10-02 0:53 ` jlnance
2003-10-02 0:17 ` [ANNOUNCE] DigSig 0.2: kernel module for digital signatureverification " Edgar Toernig
2003-10-02 2:04 ` David Gordon
2003-10-02 2:42 ` [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification " Valdis.Kletnieks
2003-10-02 18:36 ` [ANNOUNCE] DigSig 0.2: kernel module for digital signature ve rification " Makan Pourzandi
2003-10-01 14:05 ` [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification " Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F7AD795.1040001@ericsson.ca \
--to=makan.pourzandi@ericsson.ca \
--cc=Axelle.Apvrille@ericsson.ca \
--cc=davidgordonca@yahoo.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=socrate@infoiasi.ro \
--cc=vincent.roy@ericsson.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox