Protecting System Binaries From Trojan Attack

junyoung writes "Brett Lymn has added verified exec to NetBSD-current, which verifies a cryptographic hash before allowing execution of binaries and scripts. This can be used to prevent a system from running binaries or scripts which have been illegally modified or installed. Verified exec can also be used to limit the use of script interpreters to authorized scripts only and disallow interactive use."

Comments

Will this really help?

[itwerx]

If I'm writing a tool to break into a system which has this capability then I will simply pad my binary to match the size and tweak my code/data areas to be the same checksum.
Yes it's a hurdle, but methinks a minor one...

BSD Innovation

[Alethes]

I'm not a big fan of BSD licensing, but I will say that I am impressed with the level of innovation that occurs in the BSD world. The ports system, foreign binary support and now this are all examples that really tend to make me see this community as leaders rather than followers in the OS world.

User friendly Palladium ?

[Nicolay77]

I've always thougth since the invention of Palladium and al RIAA stuff that the way it can be avoided is to make something better, more secure, and way more userfriendly.

This looks like a good step in that direction. Yes, it's no the same, but that's exactly the point.

Seems backwards

[coyote-san]

This seems backwards, with a list of hashes hardcoded into the kernel.

I gave this some thought a while back, and more from the perspective of the user-space loader, and decided that it made much more sense to compile a public key into the kernel and cryptographically sign all trusted binaries.

The result is similar - you still have to verify the checksum before you load the file, but instead of having a hardcoded list of hashes that could be a maintenance nightmare you just check the checksum attached to the file itself.

It would also be easy for the kernel to determine that an executable was signed. Or you could be a bit more intelligent and stuff the signatures within the ELF file as an extension - this would allow you to protect the executable code, yet allow the initialized data (which could contain messages, etc.) to be modified.

The kernel would then only need to have a few public keys (or certs) - the project itself, an integrator, perhaps a local developer or two. Private keys, needless to say, should never be stored on the system.

All that remains is monitoring the list of authorized keys. That would be easy to do; I don't remember if BSD has a /proc FS but that's one obvious place to publish it.

Of course, since this is all blindingly obvious (it has to be, if I came up with it on my own with a few minutes thought) I'm sure that the USPTO has given a patent for it to somebody. Probably Microsoft. :-)