Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from the Debian/OpenSSL Fiasco (2008)

research.swtch.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#11

Post by est31 »

hannob wrote: post #4

I recently spend some time looking into this bug again, because I develop a tool to detect known cryptographic vulnerabilities in public keys called badkeys - https://badkeys.info/ if you're interested. Some notable things I learned: * This affects both OpenSSL and OpenSSH, but the keys are different. I.e. you have a set of vulnerable OpenSSH keys and a set of vulnerable OpenSSL keys. But the key format is the same,…

You also wrote a really great article about it! In German: https://www.golem.de/news/sicherheitsluecke-in-druckern-uebe...

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#13

Post by bombolo »

Every time this gets brought up, people forget that the patch had been sent to the openssl mailing list and someone said that it looked fine.

But here we have all the proponents of "distributions should never do any patch (and thus leave all the security issues open)". But they live in a fantasy world where all upstream authors reply within 3 minutes, fix issues within 30 minutes and of course backport the fix.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#14

Post by ninkendo »

PufPufPuf wrote: post #12

I don't quite understand why would Debian keep their own forks of software and don't even attempt to upstream the changes. Is it just security backports to ensure "stability" by not actually updating the packages, or do they have other reasons for the changes?

Where do you get “don’t even attempt to upstream the changes” from? They absolutely try to in the common case, from what I’ve seen. Every delta from upstream carries a cost, and no one knows that better than package maintainers.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#15

Post by javier_e06 »

I looked at the list of take-aways and one big important take away was missing. Testing. If a SSL depends on generating millions of unique keys then there should be an existing test somewhere the ensures that SSL does this before the release into production. The test would have caught the initialization and send the code back for re-work, clarification.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#16

Post by jmclnx »

> Try not to write clever code. Try to write well-organized code.

Decades ago someone wrote an empty loop to do "something" and it looped for a fixed number of times. No one knew why. But seemed that loop depended upon the frequency of the CPU. It was kind of a sleep (I forgot most of the details) that was needed for some reason. When the system was upgraded, things stated breaking.

That statement should be a tattoo on everyone's hand :)

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#17

Post by michaelt »

javier_e06 wrote: post #15

I looked at the list of take-aways and one big important take away was missing. Testing. If a SSL depends on generating millions of unique keys then there should be an existing test somewhere the ensures that SSL does this before the release into production. The test would have caught the initialization and send the code back for re-work, clarification.

It is extremely difficult to tell a working and subtly broken RNG apart through testing. Imagine an RNG that repeatedly ran this code:

  date +%s.%N | sha256sum
The output will never recur no matter how many times you run the test, so long as it takes at least a nanosecond. It'll pass all statistical tests of randomness.

And it's completely insecure - just guess the time and you know the output.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#18

Post by goodpoint »

WastingMyTime89 wrote: post #5
jeffrallen wrote: post #3

Wonder if any of the lessons got learned? We, as an industry, are absolutely terrible at this, but hope springs eternal...

> Wonder if any of the lessons got learned? Debian patches too much and can't be trusted is the lesson I learnt. They haven't changed their patching policy since so I refuse to use any Debian derivative and advise everyone to do so and stick to distributions which stay as close to vanilla as possible. Similarly I also think that anything pretending to provide LTS while freezing software versions is misguided and most…

It's the complete opposite.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#19

Post by 8organicbits »

michaelt wrote: post #17
javier_e06 wrote: post #15

I looked at the list of take-aways and one big important take away was missing. Testing. If a SSL depends on generating millions of unique keys then there should be an existing test somewhere the ensures that SSL does this before the release into production. The test would have caught the initialization and send the code back for re-work, clarification.

It is extremely difficult to tell a working and subtly broken RNG apart through testing. Imagine an RNG that repeatedly ran this code: date +%s.%N | sha256sum The output will never recur no matter how many times you run the test, so long as it takes at least a nanosecond. It'll pass all statistical tests of randomness. And it's completely insecure - just guess the time and you know the output.

True, but that wasn't the case here. If there were only "32,767 possible SSH keys" you wouldn't need to test very many before you'd get a collision. Such a test would have detected this issue and any similar issue that produces key in such a small set.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#20

Post by jcranmer »

jeffrallen wrote: post #3

Wonder if any of the lessons got learned? We, as an industry, are absolutely terrible at this, but hope springs eternal...

Short answer: no.

The reality of a distribution like Debian is that it needs to make patches to code to make software work in a holistic distribution, so a strict "no-patches-allowed" policy just isn't workable. The best you can hope to do is have a policy that requires at least some level of approval from upstream developers on the correctness of the patch. Which is what happened here; the only real failure that could have been avoided on the Debian contributor's was to send the entire patch for review. For all intents and purposes, it does look as if the upstream developers approved the change, and at best you're hoping that a more rigorous, formal process would have caught the fact that the people approving the change were not in fact upstream developers.

From the OpenSSL side, the faults are more legion. On the technical side, the code relied on questionable voodoo magic working correctly (when it was known that it didn't work correctly in at least some circumstances!), and the code was intrinsically confusing. On the social side, there was no clear way for a would-be contributor to identify how to get a patch approved by upstream developers. The postmortem on the OpenSSL side, however, was to point and laugh at the Debian contributor for being an ignorant n00b (it's not linked in the article), denying any fault on their part.

Perhaps it should be no surprise that a couple of years later, OpenSSL would be slammed with Heartbleed, which surfaced much of the same technical issues that the Debian bug did but without any ability to blame anybody else for making the bug. Heartbleed was severe enough to force people to learn some of the lessons they should have learned from the Debian/OpenSSL fiasco.

Post reply on HN