Slashdot Mirror


Check Who Signed Off On Your Software

An anonymous reader submits "The Software Sig Page encourages software maintainers to publish verifiable signatures for released software and to build the web of trust among software maintainers and software users. If you're afraid of downloading a trojaned OpenSSH, being 0wned while capturing packets, compiling an MTA as well as a backdoor on your system, not being able to trust tools you use every day, or never having a chance from the moment your OS boots, then you want some level of assurance that the software you use is everything the mainatainers expected you to have and no more. Look and check the MD5 and PGP signatures that come with software you download."

1 of 25 comments (clear)

  1. Mediocre solutions by Anonymous Coward · · Score: 5, Informative
    You should obtain the MD5 signature for software from a different place than you received the software from.

    This is a best-case scenario with MD5sums, and even a best case is pretty worthless. Debian up until very recently has relied on MD5sums, which are little more than a false sense of security. Yes, if the person who uploads a trojaned package forgets to update the MD5sum that goes along with it, you will know. The problem is they won't forget, they will update it, and you won't know what hit you. The advantage comes when you download the MD5sum from another site like they recommend here. Not only does the attacker have to break a second site's security (assuming they can't just break it once higher upstream, defeating this weak method of security), they have to know which site to break into to upload the MD5 to or else you will get the right one and know.

    The problem is, MD5 never protected from man in the middle attacks. Anyone between you and the internet (or some kid in the next dorm room) can simply hijack your connection (dns spoofing works great, they are close and can give a response to your dns request faster than the real server, and give their own IP address). Then once you are connected to them, they just become a transparent proxy for the site you are supposed to be using. Your software updater asks for a package that the attacker has pre-prepared, sends that instead of what you expected, and when you ask for the md5 (no matter who you ask) they pretend to be the source and give you the hacked MD5. Using MD5 for security like this is like eating leather when you run out of food. It is not acceptable.

    So what is? PGP? Yes and no. PGP allows you to trust that a developer believes that their binary and source are good. What if that developer has been trojaned? Well, I guess everybody else who uses that software is too. Look at the recent debian hack. If the exploit the attacker used worked on 64-bit systems, the main machine that signs and distributes compiled binaries would have been hacked. Great, now we have PGP signed trojans. Clearly using PGP does not make you bulletproof.

    So what do we do? I know many will be happy with nonsense like "nothing is perfect", hell, people used to argue against encryption on those grounds on the debian mailing lists. The argument went like this. People know that MD5 is insecure, so it keeps them on their toes, but people think PGP is perfect and might get lazy. Uh huh. Lets keep the system broken so that we know there is at all times a gaping hole in our system that would make the goatse man jealous.

    Here is what I think we should do. First require developers to sign their source code before release. That is just a first step. Second, have many reviewers. Lots of people read patches before they apply them to be sure that there are no back doors. These people should also sign the patches. Once there are enough signatures on source saying it is good, a distributed compilation takes place. Again signatures are compared, this time of the binaries (or a tarball of them). Yes there will be a few complications, the compiler systems will need to be similar enough to produce exact code, or the insignificant portions of the binary can be ignored in the checksum - whatever, we can handle that problem. As long as everyone uses the same version of GCC, or it is at least specified which one was used (and which switches were used for ./configure) there can now be many signed binary packages that are practically as transparent as the source code.

    Who trusts who might seem like a big deal, but really it isn't. Debian can require that the source code is verified by certain people before being compiled, and the binaries signed by certain people before official distribution. The NSA will likely choose completely different people to check source code, and have their own compile farms. Who will I trust? Well put it this way. I would want to know what both Debian and the NSA have to say, especially if they disagree. I will listen