Slashdot Mirror
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."
"cryptographic hash" != "checksum"
What you propose is not feasible, if a hash like SHA or even MD5 is used.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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.
We are Turing O-Machines. The Oracle is out there.
This seems backwards, with a list of hashes hardcoded into the kernel.
/proc FS but that's one obvious place to publish it.
:-)
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
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
This raises the constant on the level of security, but not the order of magnitude. From what I read, this just makes it more burdensome on the hacker...it's not actually introducing a new level of security. I suppose this would be good for internet 'appliances' where the access is probably limited to any holes or buffer overflows in web scripting languages. But it seems if one has access to the file system (prerequisite for trojaning anyway) this system breaks:
"Even if the file did have the same inode if the contents are modified then the fingerprint will not match anyway."
Huh?? So, the attacker just regens the hash on the trojaned binary and the kernel thinks it is the cached value...am I missing something here? Can one NOT change the cached hash without creating a seperate inode or something?
It's 10 PM. Do you know if you're un-American?
For people who want to understand more about what verified actually does, have a look at my home page which has a bit more detail on the philosophy and also a copy of the paper I presented on the subject.