Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems BSD

Protecting System Binaries From Trojan Attack 44

Posted by timothy from the matching-game dept.
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."
This discussion has been archived. No new comments can be posted.

Protecting System Binaries From Trojan Attack More

Protecting System Binaries From Trojan Attack

Comments Filter:

  • BSD Innovation (Score:2, Interesting)

    by Alethes ( 533985 )
    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 ? (Score:5, Interesting)

    by Nicolay77 ( 258497 ) <nicolay.gNO@SPAMgmail.com> on Wednesday October 30, 2002 @08:58PM (#4570212)
    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.

    • Re:User friendly Palladium ? (Score:4, Informative)

      by stevef ( 5539 ) on Wednesday October 30, 2002 @10:12PM (#4570599)
      This is solving a different problem. The purpose of this is to prevent programs that the computer owner doesn't want to be executed. Palladium and that ilk aim to prevent programs that the entertainment industry doesn't want to execute.

      Although, when/if this is presented as an alternative it will be interesting to see their response as to why it's not sufficient.

      Steve
  • 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.
    • If bash has a fingerprint in the list then you will be able to login because it will be able to run. The bit that you have picked up is that you can have, say, a perl script file that starts with #!/usr/local/bin/perl but a user typing /usr/local/bin/perl will not get perl.... this means that you can have verified scripts but prevent the shell interpreter being put to other uses.

  • Seems backwards (Score:5, Interesting)

    by coyote-san ( 38515 ) on Wednesday October 30, 2002 @11:42PM (#4570869)
    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. :-)

    • My sentiments exactly :) Promote the system from using a hash to using a MAC, and gain flexibility and simplicity.

      There is also the possibility of increased security: if an attacker finds a way to modify the hash list in the kernel, they could put in a trojan binary, or add a new verified binary. With a asymmetric key MAC system, then can't change the key without invalidation ALL of the verified binaries, which means also changing the MACs stored in/with this binaries. That's quite a bit of effort.

      But this is a great step forward.

      • Quick addition: this also allows you to introduce new verified binaries into the system without rebooting ...

    • Are *BSD binaries elf or some other format? I know they have ELF compatability layers, but I'm guessing this would be for straight BSD binaries
    • (This is surmised from the e-mail linked from the article, and may be wrong. *grin*)

      It sounds like hashes were used because, while they're a performance hit, they're not -that- big of a performance hit. Evaluating a signature (say, RSA or DSA) is more CPU-intensive than MD5 or SHA1. We're talking an order of magnitude here, maybe more. This would have to be done on each load of an executable, shared library, and shell script. Also, a lot of OSen are still resistant to putting potentially restricted crypto into kernel-level systems.

      As far as placing the signatures into the ELF binaries, the author discusses that in the e-mail and rejects it for two reasons:
      1. Doesn't work for #! shell scripts. A separate fingerprint table does.
      2. Putting the signature in the file still allows the file to be replaced, signature and all. Loading the signatures into a kernel table on boot makes it harder to munge them at runtime. It's not just untrusted executables we don't want to allow -- replacing one trusted app with another (say, ls with rm?) can be just as bad.

      Beyond that, though, I agree -- signed (rather than simply fingerprinted) files could definitely be a good thing, and I'll be watching to see how all this develops.
      • Evaluating a signature ... would have to be done on each load of an executable

        No, it wouldn't. The kernel should cache the hashes of binaries that have already been verified. So you get the performance hit only once (given a sufficiently large cache, RAM is cheap) per reboot or replaced binary.

  • I guess... (Score:4, Insightful)

    by Hard_Code ( 49548 ) on Thursday October 31, 2002 @08:32AM (#4571346)
    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?
    • as was suggested in another post, just signing binaries with a kernel key (that the installer generates uniquely! or maybe even regenerate at each boot) seems like a more solid approach (if you can automatically stick these signatures in some binary extension without actually affecting the binary executable content...otherwise it's a mess)
    • 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?

      Yes, you are missing something. You cannot "just regen the hash", the list is in kernel and cannot be updated once the securelevel has been raised. The attacker would have to regen the hash, insert it into the list of hashes to be loaded at boot and then reboot the machine. A slightly more difficult task.

      Can one NOT change the cached hash without creating a seperate inode or something?

      The hash is not cached, the comparison result is. If the file is somehow updated then the cached comparison result gets cleared.

  • Rather pointless (Score:1, Funny)

    by Anonymous Coward
    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.

  • more details on verified exec (Score:4, Informative)

    by blymn ( 621998 ) on Thursday October 31, 2002 @08:56PM (#4575752)
    For people who want to understand more about what verified actually does, have a look at my home page [optusnet.com.au] which has a bit more detail on the philosophy and also a copy of the paper I presented on the subject.

Slashdot Top Deals

C for yourself.

Close