DigSig 0.2: kernel module for digital signature verification for binaries

Hi all,

DSI development team would like to announce the release 0.2 of digsig.

This kernel module (for 2.5.66 and higher) checks
the signature of the binary before running it. The main goal is to insert digital signatures inside the ELF binary and verify this signature before loading the binary. It is based on the Linux Security Module hooks.

The code is GPL and available from: http://sourceforge.net/projects/disec/,
download digsig-0.2.

I hope that it'll be useful to you.
All bug reports and feature requests or general feedback are welcome (please CC me in your answer or feedback to the mailing list).

Regards,
Makan Pourzandi

overview
=======

Instead of writing a long detailed explication, I rather give you an example of how you can use it.

A Very simple scenraio to show how to use it =======================================

1) Generate gpg key and export your public key in order to use it for signature verification.

$gpg --gen-key

=> careful generate RSA key

$gpg --export >> my_public_key.pub

2) Sign your binaries using Bsign

Before using bsign to sign all your binaries, try out with a simple example.

$cp which ps ps-test
$bsign -s ps-test // sign the binary
$bsign -v ps-test // be sure that the signature is valid

3) Make the digsig module

From ./digsig, do make -C /usr/src/linux-2.5.66 SUBDIRS=$PWD modules. You need rw acess to /usr/src/linux-2.5.66.

CAREFULL: we advice you to compile the module in debug mode at your first tries (see -DDSI_DEBUG -DDSI_DIGSIG_DEBUG in the Makefile). In this mode, the module verifies the signatures but does not enforce the security (if not any signature present in your binary, you'll have a message in /var/log/messages but the execution is not aborted.). However, the execution of the bianaries with invalid signatures is aborted. Once, you're sure of your binary signature procedure you can recompile the whole on non-debug mode.

4) load digsig, use the public key exported in step 1 as argument

root@colby digsig-dev]# ./digsig.init start pubkey.pub Loading Digsig module.
Making device for communication with the module. Loading public key.
Done.
root@colby digsig-dev]#

5) In debug mode:

$./ps-test

$tail -f /var/log/messages

Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - binary is ./ps-test
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds: Found signature section
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds: Signature verification successful

$ps

// no check for not signed binaries
$tail -f /var/log/messages

Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - binary is ./ps

6) In restrictive mode, normal mode

You need to use bsign to sign all binaries that you want to run in normal mode.

// signed binary
[lmcmpou@reblochon lmcmpou]$ ps
PID TTY TIME CMD
6897 pts/2 00:00:00 bash
6941 pts/2 00:00:00 ps

// not signed binary
[lmcmpou@reblochon lmcmpou]$ ./ps-makan-1
bash: ./ps-makan: cannot execute binary file

// binary with wrong signature
[lmcmpou@reblochon lmcmpou]$ ./ps-makan-2
bash: ./ps-makan-colby: Operation not permitted

7) Unload the module.

[root@colby digsig-dev]# ./digsig.init stop
Unloading Digsig.

Performances
===============

This is release 0.2. We have done some benchmarks.

We ran lmbench on a Pentium IV, 2.4 GHz, 500 mega bytes of memory, running Linux 2.5.66. Our benchmarks show that the execution time (exec function call) multiplies by a factor of 4 when the module is loaded (no changes for fork call, as the binary is not loaded into memory).

Some details
==========

The module is independent from DSI (parent project) and you don't need to download the whole dsi tar ball to play with the digsig module (even if we'll be more than happy to have your feedback about dsi project :-)).

Our approach has been to use the existing solutions like gpg and bsign rather than reinventing the whole thing from scratch.

However, in order to reduce the overhead in the kernel, we took only the minimum code necessary from GPG. We took only the MPI (Multi Precision Integer) source code and the RSA crypto source code. This helped much to reduce the amount of code imported to the kernel in sourc code of the original (only 1/10 of the original gnupg 1.2.2 sourc code has been imported to the kernel module). On the other hand, we avoided OpenSSL source code for the fact that the licensing was not clear to us. We did some tests at user level and found out that OpenSSL is 4 times faster than GPG regarding RSA verification. As a future direction, we plan to clarify this licensing issue and use OpenSSL instead of GPG.

Requirements:
==============

Linux OS kernel 2.5.66 or higher. We tested against 2.5.66 and 2.6.0-test5.

Bsign version
0.4.5. (http://packages.debian.org/unstable/admin/bsign.html)

GPG 1.2.2 or higher.

Merits
=====

This work has been done by (alphabetical order)

A Apvrille ([email protected]),
D Gordon ([email protected]), M Pourzandi ([email protected]), V Roy ([email protected]).

Special merits go to David who wrote big chunks of the source code.

Thanks to Radu Filip ([email protected]) which has done the initial study for this work.

Thanks also to Marc Singer who helped us in using Bsign.

Regards,
Makan Pourzandi
-------------------------------------------------------
Makan Pourzandi,
Ericsson Research Canada [email protected]
This email does not represent or express the opinions of Ericsson Inc.
-------------------------------------------------------

Hi!

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...
Pavel

When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

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.
-------------------------------------------------------

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.

Rubbish. You don't need to compile anything locally and the rest will be done once by some wanker with half a clue and then repeated by wankers without a clue (aka script kiddies).

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

<shrug> so in a month rootkits get updated and we are back to square 1, with additional mess from patch...

Hi Al,

I think that's perfectly true, sadly. It may even become the subject of the phrack article, next to the collection of insmod_without_module_support, etc...

The only useful feature it would provide would be to secure a system against people who tamper on the media itself, which is fairly trivial on nfsroot. It may be interesting to ensure that a server farm which all mount their root from a central server may not be tricked into executing undesired code injected into the central NFS server.

The same would be true for removable media such as smartmedia, on PDAs or specialized systems.

Just a few thoughts,
Willy

Viro, I think you have an attitude problem here. "Don't be ridiculous", "Rubbish", "<shrug>" don't sound very constructive or at least encouraging.

Over the years it was proved that Linux kernel can be tailored for a very large number of unexpected and very strange needs. IBM put it into watches, NASA sent it to space, it is exists in oil wells and so on. I think that the possibilities offered by Linux kernel are limited only by the knowledge, imagination and will of every of us. Linux itself was once a very insignificant and unreliable kernel and many other serious Unix and Unix-like alternative were available. Still, it is prevailing today because some peoples believed in what they did.

Especially to your point, should I mention that there are patches that avoid buffer-overflows? Or that there are patches for gcc that add bound check to arrays in C?

These peoples are trying to solve a problem. If you have some expertise in the area of the problem, it might be much useful to come with positive ideas about how the encountered problems can be solved, instead of dismissing with so much ease the effort done to solve a real problem.

Come on, I'm sure you can Think Positive (TM).

Regards,

Hi!

I simply wanted to see valid usage of this. It certainly does not prevent attacker to get control of your box. Al seems to be right. It may temporarily redirect script-kiddies, through...

There may be some uses like "prevent tivo users from running their own software", but I'm not sure I want to encourage some uses. Maybe "its neccessary to get our phones approved by FCC" would be better.
Pavel

When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

[...]

Al does real work and is about substance, not "Think Positive (TM)" or any other fad du jour. I tend to agree with him the most when he is the most caustic, all he is doing is speaking the truth. If you can't handle it, go someplace else. I *like* what he says because it is true.

---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

At the same time take a look at:

http://www.bitmover.com/lm/quotes.html

and read the quote about politeness. It makes a lot of sense, and I was impressed when I found it the other day.

Thanks,

Jim

The "How do I make sure that only licensed software will run on my new gizmo?" problem?

Why should an open source developer encourage this?

Ciao, ET.

PS: If you really meant security then browse around and see how the X-Box was hacked...

Digital signatures in open source software are aimed at running only allowed (read signed) binaries, the license question is a side issue. IMHO, this has a potential to increase the security of a Linux box.

That is true. A digital signature will only protect binary data on hard disk. The whole process from the hard disk to memory is harder to cover (see
http://www.phrack.org/show.php?p=59&a=5 Short Stories about execve). I believe that digital signature verification in the kernel must be placed as close as possible to the actual mmap of the binary. LSM framework is the current way of implementing this but not quite sufficient.

local

That's also true. A digital signature will not protect against an already existing vulnerability in a binary (bo). Let's say for instance that a linux box is compromised with a bo, usually another backdoor is created. Even if the system is running Pax (mentioned by Makan), "http://www.phrack.org/show.php?p=61&a=8 Cerberus Elf interface" describes how to circumvent this.

But on a system with digitally signed binaries, this is no longer possible since it requires modification of the binary which is signed.

My point is that a system with digitally signed binaries won't prevent existing security holes, but will prevent the creation of other ones. The attacker is constrained to use the system as is, ie. to exploit the same bo. Unless of course the bo gives him access to the kernel and he disables digital signature verification.

David

______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca

Hmm.. patches to avoid buffer overflows.. hold that thought.

Also, note that those gcc patches are in general inadequate, in that they can't do much for the most common case of a bounds-check issue in C - where a pointer to a char array is passed to another function which uses it as the target of a strcpy() or such...

(Not to say that the patches are useless - but they're a lot less utility than sounds at first, precisely because most C code relies so heavily on the interplay of "array" and "pointer", especially when calling another function)

(Note that I'm writing this as somebody who is himself running the exec-shield patches *and* the SELinux stuff and a few other things as well... so I don't consider this stuff *totally* useless....)

The problem here is that "positive ideas" in this case *DOES* include the observation that the only thing the patch does is raise the bar on a purely temporary basis, and that it provides little long-term benefit as soon as the rootkits start working around it. As has been pointed out, DigSig only secures one tiny part of the way that executable code gets into memory.

Yes, it probably does a *very* good job of making sure that the binary loaded by an exec() call hasn't been tampered with. On the other hand, it does *NOTHING* to tamper-proof shared libraries - so if the attacker had a nice trojan to put into /usr/sbin/pppd and you install DigSig, all they have to do is wrap a 'if (!strcmp("pppd",argv[0]) {....' around their code and stick it in /lib/libutil.so instead. Or drop it into the PAM directories. If the attacker could otherwise have modified pppd, they almost certainly had the ability to modify libutil.so or the PAM stuff as well.

You're spending a lot of effort solving the problem of making sure that you can't exec an untrusted binary, when the problem you (presumably) actually want to solve is making sure that you can't run untrusted code.

Note that Microsoft's literature on their Trusted Computing initiative seems to indicate that they made this same mistake - they fail to account for the fact that if you install a Palladium-aware IIS (or whatever), and then manage to buffer-overflow it, that code will then execute in whatever context the IIS program has. As such, it's more about DRM than about actual security.

I agree, one major improvement would be to extend our work to the shared libraries. Quite frankly, I haven't had enough free time to find out how to handle this one. Our first investigations showed that there would be no appropraite LSM hook that could handle this. I want to put the emphasis on the fact that I didn't spend much time there, so we'll see after i spend some days bugging around the code.

Can you elaborate more in this? I don't agree that what we do has something to do with DMR.

I believe there is some misunderstanding, we do not assume that the authentication of the binary is done by using public keys from big industry names or any, we believe that this authentication must be done
using admin's public key (or user's) on the system. and this is how we implemented digsig. our approach lets free hands to the
admin (or user) to organize the system as he believes to. In our approach, the
code is signed by the __admin's__ private key. Then the binary is verified by the public key introduced by the __admin__. This means
that you could always sign __all__ binaries you wanr on your system with your own keys and have absolutely no problem running them. The only thing Digsig garantees you is that if __you__ signed a binary, nobody else than you (or people that you allowed) can change that binary and run it in your system. But nobody can forbid __you__ from running the binary. I see that we give more power to the admin (or user) over how s/he wants his system to run rather than enforcing any DMR alike approach. digsig approach is based on __locally__ signing all binaries, we don't support any kind of signature verificatin from binaries coming from outside (our documentation is not yet there but see bsign's docuementation for more details)

To simplify things, our approach is much closer to Tripwire than any kind of DMR alike that I heard of; AFAIK, Tripwire allows you to sign your files and check their integrity upon the time. to over simplify, this is somehow what we do but for binaries only and at run-time. btw, even to simplify more, isn't that similar to what we do when we accept to verify the md5 or signature of a rpm which we download from red hat?

regards,
makan

-------------------------------------------------------
Makan Pourzandi,
Ericsson Research Canada
*This email does not represent or express the opinions of Ericsson Inc.
-------------------------------------------------------

The idea isn't to stop you from calling exec*().

The idea is to ensure that if you do execve("/usr/bin/foobar",...) that the foobar binary hasn't been tampered with and you're not about to launch a binary
differing from what you expected. Note that on a properly administered
system, this is a *high* level of paranoia, as the file permissions should have prevented writing to the binary in the first place. It's also a maintenance nightmare waiting to happen, as you get to re-sign all the binaries every time you install a patch, and it won't help prevent trojaned shared libraries...