Software security--a matter of trust

We make security trust decisions all the time--for instance, when accepting or rejecting a digital certificate prior to downloading software. But can we know whether the software we download is truly safe?

Maybe not, as recent attacks against well-known open source software sites suggest. Both attacks were against the source code distributions of the products, not the binaries, and both took the clever step of compromising the build process, rather than the actual executable produced. The first attack was against OpenSSH, a popular open-source secure shell tool. The attacker appears to have planted modified sources on the OpenSSH FTP server. For a one- or two-day period, anyone who downloaded some versions of OpenSSH and built the sources was vulnerable; the attack code connected to a particular host over a port 6667.

The second attack was against the venerable Sendmail open-source e-mail server. As reported by ZDNet News, the compromise of the FTP server was different in this case. Instead of changing the actual files on the FTP server, the FTP software was compromised to redirect the user to Trojan files on a different server outside of Sendmail. But the Trojan horse itself was very similar--triggered in the build process of the source code.

Experts are debating whether the same attacker perpetrated both attacks, since they certainly have a lot in common. And these are not the only cases in which programmers-gone-bad have attempted to distribute code by compromising FTP servers on popular download sites.

There are tools and systems available to help us all avoid getting victimized by this particular problem. The short answer is digital signatures. If everyone digitally signed all their distributions and checked the signatures against correct public keys, it would be extremely difficult--and effectively impractical--to slip one of these attacks past anyone.

Public key cryptography is so old that the patents have actually run out on the initial key discoveries. And yet for the most part the software to use it generally retains 1980s-style usability.

Very often users are advised to confirm the integrity of downloads by checking the files against the MD5 checksums. These are numerical values distributed either with the files or separately, and are a function of the contents of the files. If the contents change, so should the checksum and therefore a user would be alerted to discrepancies. And it's certainly a good habit to confirm your checksums, but it's not a perfect solution to the problem of malicious insertions of Trojan horses.

Checksums are meant to check for accidental changes, such as errors during transmission (although I think that network protocols check for this as well, so I doubt that MD5 often finds actual transmission errors). The problem with checksums is that an attacker talented enough to modify the sources you receive is probably talented enough to modify the checksums so that they correspond to the modified files.

This is why public key cryptography is so important. If the attacker doesn't have the private key of the person/organization you expect, they're not going to be able to fake it.

Apart from the famous PGP, there are public open source alternatives like GnuPG (Gnu Privacy Guard), a largely compatible GNU implementation of PGP using a different, non-patented algorithm. Many open-source distributions are signed by the author or organization's key. Some Linux distributions (or at least their package manager tools, such as apt-get) automatically check the MD5 checksums, which should catch problems such as these. Red Hat signs all its RPM packages, and these are checked with some of its higher-level tools like up2date, but with RPM you have to manually use the "--checksig" switch.

In my experience, Microsoft has been digitally signing most--but not all--of the code they distribute, for many years. In fact, the whole ActiveX infrastructure in Internet Explorer, which was predicted from the start to be a hacking disaster, has experienced very few compromises because users are always presented with a digital certificate before the browser installs the code. If you see that the code is not signed or perhaps signed by "Leejunz of Doom," you just say "no thank you" because you don't trust the source. Few attackers have even attempted this, and ActiveX is widely used by widely trusted vendors like Adobe and Macromedia.

From an end-user standpoint, Microsoft's Authenticode makes checking digital signatures about as easy as it can be, and its internal procedures for assuring proper use of the signatures are imposing. According to Scott Culp, Manager of Microsoft's Security Response Center, "We digitally sign all executables that we distribute. The number of employees who can sign executables is strictly limited, access to the signing tool requires special authentication, and every signing request must be vouched for by at least two other employees. The Authenticode technology that ships as part of Windows verifies the digital signature when the user installs the patch or tool."

But PKI in general isn't used enough. Consider that the hacked Sendmail was available for over a week! Even though the evil version was delivered only 10 percent of the time (the guess is that about 200 users downloaded it), the longevity of the attack tells me that very few people are confirming their files either through checksums or public keys. Perhaps this is even more the case with source files; my initial thought, a stupid one in retrospect, was that compromising a source file was like begging to get caught. The source, and therefore the attack, would be out in the open. But in fact, the old axiom about hiding applies here: You hide in a place where you blend in, and an attack in source code just looks like more source code.

Another real problem with PKI has always been key distribution. Where do I go to get the other user's public key? Companies like Verisign offer services, including enterprise services, for outsourcing PKI infrastructure. But the real solution has to be a universal one, and the software is still too much of a mess to be universal.

PKI doesn't solve every malicious code problem. For instance, if the developer's machine is compromised and their files are changed right under their noses, it's possible that they will sign and distribute the compromised files. Of course, if you can't trust your own source files on your own system, the world is really coming to an end. Whether you trust Microsoft or not, they're right when they speak of a future of "trustworthy computing."

What steps are you taking to improve your company's software security? TalkBack below or e-mail us with your thoughts.