Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Protecting System Binaries From Trojan Attack

Posted by timothy on Wed Oct 30, 2002 07:59 PM
from the matching-game dept.
Operating Systems Security BSD
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."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Protecting System Binaries From Trojan Attack 44 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

    • Re:Will this really help? (Score:5, Informative)

      by ChadN (21033) on Wednesday October 30 2002, @08:27PM (#4570034)
      "cryptographic hash" != "checksum"

      What you propose is not feasible, if a hash like SHA or even MD5 is used.

      • Re:Will this really help? (Score:1, Informative)

        by Anonymous Coward
        It is. MD5 or SHA1 choice on a per-file basis. With the ability to add other algorithms as required.
    • If it were so easy to modify a working malicious binary to match the checksum/md5 or any other hash, why would it be used so often as a method of file verification? I'm thinking it'd be a lot harder to make this happen than you're implying.
    • Easier said than done.

      If they use a CRC [repairfaq.org], it could be difficult to get something to the same checksum. Even if it's only a 32 bit CRC, there are a lot of numbers between 0 and 2^32 - especially when they are the result of some unknown hash function.

      That's not to say it couldn't be done - the idea is akin to the 'The Club'(TM).....

    • Re:Will this really help? (Score:2, Insightful)

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

      Well, it would appear to be the case at first glance, but you have to remember that cryptographic hashes are designed to solve exactly this problem. It is much more difficult than you think.

      Or perhaps better stated: show me the code.

    • Ummm *hello* is does actually say "cryptographic hash" in the article there. The fingerprint is either a md5 or a sha1 hash not a simple checksum. Though you could add a checksum method if you wanted a smoking hole in your foot.

  • 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.
      • how can you -not- be a fan of BSD licensing? You can do anything you want with the code!

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

        • IT is free. (Score:2, Insightful)

          by mindstrm (20013)
          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.

  • User friendly Palladium ? (Score:5, Interesting)

    by Nicolay77 (258497) <`nicolay.g' `at' `gmail.com'> on Wednesday October 30 2002, @08:58PM (#4570212) Homepage
    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 ...

          • I think what the parent means is that you shouldn't keep checksums in the kernel but a public key. It's simple. You put a public key into the kernel and have the private one on a secure computer without network access.

            Say you want to update your server. You put those binaries on a floppy or whatever, take them to the signing computer and sign them. Then you copy those binaries to the server with the signature.

            Since you can't fake a signature the kernel can verify that the binary has been signed by you. If you used the checksums idea you'd have to keep a checksum per file, which probably would require a recompilation and a reboot every time you wanted to update something.
    • 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.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.