OStatic

OpenSSL and Debian: A Cautionary Tale

 We don't normally cover security advisories here on OStatic. There's just not enough space to do them all justice, and besides, other folks do a fine job of tracking such things. But a recent vulnerability in the Debian version of OpenSSL is worth spending some time on, because it's a case where the open source system failed for a long time to do its job of producing quality software.

Before I get into the details, here's a warning just in case you've missed the brouhaha: If you're running Debian or Ubuntu, you need to follow those links to the appropriate security advisories and patch your system. If you don't, and the system is out on the net, some hacker will be along presently to log in via SSH. Don't say we didn't warn you.

Now for the back story: in late 2006, the Debian developers decided to fix an unitialized variable issue in the OpenSSL package that an automated code-checking tool had warned them about. Unfortunately, OpenSSL was using this data as a source of randomness to aid in key generation. The net effect is that affected systems - basically, anything based off of Debian or Ubuntu until just recently - could only generate one of 32,000 or so keys. This is bad. It means there are so few keys that brute-forcing the security on those systems is trivial (it's become even more trivial as lists of all possible keys have started circulating).

The exact details of how this bug shipped for so long without being noticed are in some dispute, with the OpenSSL and Debian developers doing some finger-pointing at each other. Depending on how you read the story, the Debian folks didn't tell the OpenSSL folks what they were doing, or they told the wrong OpenSSL folks, or they told them and got the go-ahead, or they told them and misunderstood the reply. But in any case, the damage is done, and it's widespread damage.

Hindsight is always 20/20, and it's easy to try to lay blame here. But instead, let's think about some principles that could help prevent such disasters in the future. It seems to me that there are three things that would have helped immensely in this case, even if (as happened) the communication between different open source communities broke down.

First, don't assume that other open source developers are idiots. If the security guys at OpenSSL had been shipping an unintialized buffer for years, it would make sense to assume that they're smart guys who know what they're doing. Sure, even smart people can leave bugs in code - but that shouldn't be the default assumption. If some tool tells you there's an issue in software that's already been inspected by many eyes, you should at least think about mistrusting the tool.

Second, your caution in fixing bugs in other people's code should be proportional to the importance of the software. While it's not unreasonable for a distribution to want to improve the software that it's incorporating, some common sense would be nice. Changing the user interface of a text editor is one thing; messing around with core security software is another. If you really think that there's an issue with something that important, you should take it up with the package maintainers rather than fixing it yourself. Or become one of the maintainers - most open source projects are happy to have more hands and eyes in their process.

Third, open source developers should not assume that their code is blindingly obvious. I've looked at the original code in this case, and although it is fairly well-commented, some of the key details of the algorithm will only be obvious to those who have had to deal with the problem of generating entropy before. One more block comment explaining "Now we generate entropy by..." would likely have prevented the whole debacle - though it would have also seemed too simple to bother writing to the package maintainers. But given that we expect our code to be inspected by many developers of varying degrees of skill (whether to patch it or to learn from it), I'd recommend erring on the side of caution.

• security
• openssl

by an anonymous user on May. 21, 2008

Wonder how folks would react if the Debian and Ubuntu people did not fix this when the tool showed it as a possible issue, and it did turn out to be a vulnerability?

Though your principles are valid and maybe considered obvious, think "Hindsight is always 20/20" has more to do here.

0 Votes

by orcmid on May. 21, 2008

What gets me is the assumption that an uninitialized variable will provide a value that is regarded as sufficiently-entropic.

There is the assumption that if the code doesn't initialize the variable, nobody else does, and that what is found there can't be predicted with some degree of success.

An explicit entropy scheme would be far more robust and defensible and would not have led to this weirdness.

0 Votes

Share Your Comments