Fixing Debian OpenSSL

No Apologies, just the facts

Ah, but. I do my job and I do check. I didn’t want to put the blame on one person, but since you brought the matter up. the person cited is Kurt Roeckx: the Debian OpenSSL maintainer.

http://qa.debian.org/developer.php?login=Roeckx&comaint=yes

He’s the one who made the mistake. If you read on in the thread. you quote, you’d see that someone gave him the flag to make the debugger code work properly with OpenSSL

http://marc.info/?l=openssl-dev&m=114654760312453&w=2

As I mentioned in the story, people had been running into this problem for years and assuming, incorrectly, that the problem was with OpenSSL and being corrected. The difference here is that he was in a position to mangle OpenSSL to ‘fix’ what he thought was a problem and he then didn’t pass it upstream. So, it’s still a Debian problem.

Then, someone at Debian, presumably Roeckex since it’s his project, decided to fix the problem a few days before it went public without telling anyone.

See Ben Laurie’s blog

http://www.links.org/?p=327

for details and pointers to the patches.

For more on what actually happened, see: Gregely's blog posting: "Debian’s OpenSSL maintainer (Kurt Roeckx) should be changed"

http://www.gergely.risko.hu/debian-dsa1571.en.html

Sorry, this was clearly a Debian problem. Trying to poison the well about people who report on it doesn't change the facts.

Steven

Please, your logic makes no sense

What does this mean, "he then didn’t pass it upstream" ? There are no secrets in Debian code, each patch is clearly documented and listed in the package. Not difficult for anyone to find. Nothing hidden.

Is the Debian maintainer somehow required to sent a personally addressed email to each upstream author saying "here are my patches" ? What would be the point? For anyone who wants to check, they all know where to look. They can just take a quick glance at version number updates and changelogs once every few weeks. Why fill more email boxes with yet more junk? Maybe sending a brass band would be even better.

Are you suggesting that Debian must actually get written approval for all changes from an upstream author? I hope you understand just how stupid that suggestion is. I hope you also understand that upstream authors can also make mistakes. IMHO depending on unitialised memory as a source of entropy is much more dangerous than not having the entropy. My reasoning is that it is a false sense of safety -- if you can't trust the code under adverse conditions then you can't trust it at all. It is also (perhaps) a door for some untrusted input data to systematically manipulate your random pool. Linux has /dev/urandom and /dev/random which are the official entropy suppliers (supported by hardware entropy generators in most modern systems).

The Debian maintainer was actually doing the right thing, he just got overzealous and commented out TWO lines of code in TWO places (one of which had nothing to do with the original problem, and caused a new problem). Now, from the code, it is obvious that an earlier upstream author had been running "purify" and run into exactly the same issue (for the same reasons no doubt) and even put a conditional directive to handle this situation... but they were too lazy to put a comment to explain what was happening and why they chose a slightly questionable design decision. That in itself is a sign of poor engineering teamwork and unmaintainable code. The real blame falls on people who can't document their design properly.

Actually...

Linux proponents have always been touting Linux as the ultimate security thing because there are so many eyes looking at critical code that any bug is quickly caught and fixed.

It WAS caught, and immediately addressed.

Yeah, it took a while, but apparently the bad guys didn't know either. I haven't heard about any crime waves involving Debian system attacks.

right... caught 2 years

right... caught 2 years later...
Microsoft too "immediately" addresses a lot of vulnerabilities...

Fact is, it will take forever to fix all the damage caused by this small hack... It is a very persistent bug - it's not like you can just patch your binary and crush that buffer overflow - changing all SSH keys generated over the last 2 years is a massive task..

And while there might not be a crime wave on Debian systems, I am sure that all bad guys have already incorporated attacks based on this into their toolsets, and in months to come plenty of systems *will* get compromised...

Look, I am not arguing that open source is bad. I am just saying that this is a pretty bad fiasco, both in PR and in actual damage.

As a fact check, the supposedly thick-headed Debian developer went to the openssl-dev group and asked if he can remove those lines... Fact is, none of the OpenSSL guys exploded "NO, DON'T DO THIS!".. One person told him to compile with -DPURIFY, which was, admittedly, the correct thing to do - but nobody told him that removing the second line would cripple the PRNG..

True, it was a BIG fubar

But my point is that as soon as it was discovered (yes, two years after the fact) fixes were sent to machines via updates almost immediately. When a flaw is discovered in FOSS, that is ALWAYS the procedure. With anything proprietary (not intending to start the ultimate MS/Linux debate that will spring up here sooner or later!), you wait for the software's developers, and hope they hurry. They certainly don't always do that.

And yes, the pain of key regeneration is very real. An example of doofus-headedness snowballing, to be sure. But the fix is there NOW.

True

This I definitely agree with. Reaction time is great. The problem here is more about trust than anything else... oh, well, things will probably improve over time.. perhaps Debian's arrogance will subside a little, perhaps users will go to other distros that don't fiddle randomly with all of their packages..