Open Source Security Critique Criticized

OK, I don't know about you (well, perhaps I do :), but I don't get most of my binaries (even on Linux) from sources that have cryptographically signed them, and I'd think most others don't, either. They probably should. But I don't think they do.

I seem to recall, in the dim dark days of the 80's, that someone somewhere diddled with one of the news-servers in a spool directory somewhere. (Someone with access, obviously, either real or acquired)

The upshot was that a magic control message could be generated and sites running a binary generated from the affected sources would create root logins in /etc/passwd when they recieved it. Who checked? I recall hearing of sites that got burned, and our own sysadmin at the time started obtaining the source on 16bpi magtape, as did others around that period.

When we were monitoring a cracker at the local university a couple years ago (some 30 minutes prior to his apprehension and arrest), we saw him script-kiddying his way into network after network. Capturing packets between his workstation and the university machine he was cracking from, we were able to more or less see what he was seeing. After a particularly tough crack, we actually stood up and applauded (much to the bemusement of the federal policemen with us).

....Then he cracked into the central GNU archive server and left his back-door there, and we got really quiet. My partner swore after a moment, and we just thought through the implications. Anyone using the same toolset could get in and take root there from that moment, and not everyone was just kracking-for-kudos. We made an attempt to explain the implications to the policemen, who were a trifle blank about it all, then we just gave up and told them 'Grab this sucker. Now. The damage is potentially incalculable', and got one of them to arrange a fax to MIT.

And yes, I don't check the damn signatures either and I should.

It's like backups and virus scans. Until you're bitten the first time, you don't.

Digital signatures on software are not a whole lot stronger than the distribution mechanisms themselves. The fact is that most private keys are held on disk on workstations, and if you can break into the server you can probably get into the workstation too.

Red Hat packages from Red Hat are internaly signed. Debian packages are signed and the signature checked before they are added to the official CD set, I think the signature data may not be stored on the CD in the current release, though. Debian has decided to store the signature in both the package file and in an external file, so it will be transmitted to the user in the future.

Yes, some people are sloppy with their keys, but note that even if they are on hard disk, they are protected with a password-based encryption.

Thanks

Bruce

Yes, some people are sloppy with their keys, but note that even if they are on hard disk, they are protected with a password-based encryption.

Unfortunately, it's not that simple. For a key to be useful, the owner must eventually enter that passphrase, at which point it can be stolen from memory or copied by a patched keyboard controller.

One may, as manoj put it, disconnect the network, boot from read-only media, mount floppy, sign package on floppy, unmount floppy, reboot, reconnect the network. This should be just as secure as the packages on the read-only system, barring hardware modification or other forms of non-software surveillance. And more trouble that most people are willing to go to.

Are you feeling paranoid yet? :^)

To spread a trojaned binary you don't need to hack a server. Yeah to get the Redhat packages to be trojaned you do, but you just need to get your binaries advertised. Stick a comment after a Freshmeat announcement "Get binaries for XXX here".
This way digital signatures are fairly useful. I'm not sure if I've lost my point...

One may, as manoj put it, disconnect the network, boot from read-only media, mount floppy, sign package on floppy, unmount floppy, reboot, reconnect the network. This should be just as secure as the packages on the read-only system, barring hardware modification or other forms of non-software surveillance. And more trouble that most people are willing to go to.

This is just one of many reasons why I started Lubbock.

We're still working on this, but the plans are that you'll select the items you want on the CD from a long list, include your private keys and other info, and then make a CD image. We plan on using trusted packages (probably Debian), so you'll know your bootable CD is 100% secure.

It'll include the tools you want, so you can create a CD that boots, mounts your existing partitions, connects to the network, signs and uploads your package via SSH, and bingo, you're done. We plan on it becoming a work environment, not just a once in a while thing you load. Even if it is r00ted, a reboot restores the system unrooted, and then you'll just need to build a patched CD to fix the hole.

Someone would have to duplicate your CD in order to compromise the security of your trust network then. Don't let the CD out of your sight, lock it up in a safe, etc, and you'd be fine. Or for the truly paranoid, we are using a compressed (zlib) filesystem. I'm sure we can modify it to use a password/key scheme, and then you memorize that, and the system won't uncompress/decrypt without that. About the only thing it won't protect against is that new keyboard that records keystrokes. But even that is workaroundable, since you might never have to type passwords if they are already on the CD.

Lubbock is meant for all of those moments when you absolutely positively trust no one, and can't even trust your local machine (trojans, keyloggers, and packet sniffers! oh my!)

Bruce said it in a different article over a year ago. Debian has some great tools and packages. The Debian team has laid the foundation for the most secure Linux distribution --- however the job isn't done yet!

They do use PGP/GPG extensively. All packages are signed as prior to upload (and apparently checked automatically as they are incorporated into the master archives). The debian maintainer's keyring is available as a Debian package (apt-get'able, of course). GPG has matured nicely.

Now we need to take it a couple of steps further. Debian needs to make detached signatures available through their archive system. The signatures obviously should be signed by the maintainer (I know that sounds recursive, generate a detached signature for a binary package, then sign that).

The debian keyring should be signed by Wichert. Each key on it should be signed by at least three other Debian maintainers. So, new maintainers get their key signed by their sponsor, and two other maintainers.

If we followed this protocol, we'd build a decent web of trust in the Debian community.

More importantly the signature checking must become the default for all dpkg and apt-get operations that fetch and install new packages. Users shouldn't have to take any extra steps to perform this operation.

Now, I know I might be causing some debate here. Nobody wants to hear: "Thou shalt install GPG!" when they install their distribution.

When I say "become the default" I don't mean to dictate that every system have GPG installed. I mean that the packaging tools should look for GPG and the Debian maintainers keyring, check their integrity and then use those tools to check the integrity of the packages that are being installed.

I mean that the installation of GPG and the maintainer's keyring should be become "recommended" and that warnings should be issued any time these tests cannot be completed. (Nagging users about their lack of security).

I also would like to help develop a tool to perform a full system audit on a Debian system. This would involve rebooting from a CD or write-protected floppy --- so we have a full "trusted path" from system power-on through the auditing process.

Obviously I need the have an available signature base before I can do more than simply check the system's contents vs. those of the .deb/data.tar.gz files.

BTW:To test the integrity of the system files vs. the contents of a "presumed to be good" set of .deb files use the following command:

for i in *.deb; do ar p $i data.tar.gz | tar dz ; done

We seem to have overcome the most egregious of the disgusting U.S. export regulations (since we can now freely post crypto sources to the 'net with a mere formality of notification). It seems that we still can't post binaries freely. However, it appears that we can make scripts to fetch, build and install binaries from sources, so that is of diminishing practical consequence. (NOTE: we must not get complacent in the fight for free crypto) (Also Note: IANAL)

So, I think we have laid the foundation and brought all the requisite tools to the job site. However, we still have to put up the walls!

From memory:

Dan Bernstein's legal team, in correspondence with the Commerce Department about his lawsuit, was told that compiled versions of open source software could be posted on the Internet under the same exception.

Bernstein's team complained that this interpretation was not obvious from the regulations and could not be relied on until the Commerce Department was willing to make a public statement to this effect in writing. I don't think they have done that yet.

It should be possible to confirm this by looking in the EFF's Bernstein case archives.

Unfortunately I have to agree with Aleph's heresy. Opening your Source code by itself does nothing to improve its security. People have to actually look critically at it.

It is easy to dismiss such criticism by stating that closed-source vendors have no such review process, but this is patently false. Many vendors of closed source software have formal code and security reviews. Such exercises are absent from most open source projects. People are generally more interested in adding features than the relatively unsexy task of auditing code.

OpenBSD do a great job of security, but no-one else seems to profit from their hard work. Linux distributions have recently found to be shipping vulnerable software that OpenBSD fixed years back (recent lpd hole).

Is this changing? No - looking through Freshmeat shows more software than ever being written by inexperienced developers (here's a fun challenge: pick a recently-release "encryption" program from Freshmeat and break it - most are XOR variants). Systems are becoming more complex. Developers do not practive defensive programming (my GNOME system listens on about 10 public TCP ports).

I tend to agree with Elias about his concerns with open source software. Open source provides us with great opportunities for improved security, but with a few notable exceptions, it's the same old thing. The only thing that makes a difference is when careful and rigorous security-aware software designing takes place--it's not clear that in a software-free-for-all environment that there will be any improvement--infact, it may be worse. It's amazing what gets shipped with setuid bits turned on in the RedHat packages for the base system, and in the FreeBSD packages collection. It seems like anyone can write a piece of code and have it installed with privilege on a million desktops.

Without strong quality control and substantial influence in the design by security-aware developers (read: paranoid nuts), there will be no improvement. I've seen far better security development techniques in commercial environments where something serious is on the line for the developer if they screw up: their job. I am quite willing to admit that commercial venues can release piss-poor software, but I also suspect that the commercial environments is going to be closer to the type of environment where security can and will be in the fore-front of the developers mind.

Don't get me wrong: I'm all for open source software, and improved security. But it's *remarkably* hard to get security reviews for security changes in any piece of open-source software, let along getting security reviews for non-security. Security just isn't a priority in the ``release early, release often'' mantra. changes.

As Rillian stated, there are issues everyone needs to understand in regards to digital signatures. Debian, Redhat, SuSE, and many other vendors use OpenPGP signatures on their products and security alerts, and this is good. The feasibility of compromising the keys, given a good security policy, is limited.

Obviously if the system that contains such keys is compromised, the pgp or gpg executable could be trojaned, passphrases intercepted, or other Bad Things done to obtain the secret keys.

However, it is much more likely that someone would try to inject a compromised program into the community if verification of digital signatures or hashes weren't an issue. As General Douglas MacArthur said, "There is no security on this earth. There is only opportunity."

It is our business to limit that opportunity in any way we can.