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."
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...
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.
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.
how can you -not- be a fan of BSD licensing? You can do anything you want with the code!
one TCPA/Palladium enabled CPUs become available this type of thing can be improved upon by storing the allowed executable hash table in memory that is protected from the rest of the system (true immutable data!).
In that case, I live in your butt.
--Giving to trolls for the benefit of us all
Maybe he doesn't feel freedom is worth it if other people get it too...
Bash is a "interactive" session.. if this is installed you won't be able to login? I am not saying this is a bad thing, I just want to remind people that security is an onion. As long as your system has many layers the hacker has to go through, it will make him cry eventually and find another computer to hack. Nothing is unbreakable by itself, but there is a point to where your computer is more difficult to hack than it is worth it.
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
a local company here in Phoenix, AZ, implemented something very similar. they forked freebsd and called it securebsd.
8 &oe=UTF-8&newwindow=1&safe=off&q=securebsd+firewal ls
... Re: SecureBSD (Was: Re: Firewalls and the endless story!)
problem is, the license they used for securebsd was truly shit.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-
first thread
looks like Darren (in his post) was referring to this very NetBSD feature.
...and that's possibly the problem. If I write something and release it for the world to use, I want them to give their changes back to the world also. I want it to stay free.
-- Even if a god did exist, why the fsck should I worship it?
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?
How would you do that with a script?
Well, okay, I can see why you wouldn't want to BSD-license your *own* code, but you can't have anything against someone elses BSD-licensed code, can you? You're allowed to do a lot with it, including everything that's allowed by the GPL, and more.
About "staying free", it's true that someone can take BSD-licensed code and make a proprietary product using it, but *the original and free code stays free and available to everyone*.
Why not do what Redhat does and try to find another 10
different ways to colorize file listings. Everybody
knows that only by having the most ways to colorize file
listings will you actually have a better operating system.
Nobody cares about how good your tcp stack is or
if you have a more secure operating system. Its all
about colorizing file listings.
The code you wrote is freely available to all.
Code others make out of it may not be.
So you want to dictate that only those people who are going to give code away are allowed to modify your code. That's fine, just don't pretend it's about freedom.
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.