The Debian/Ubuntu key generation flaw

It’s all in the news these days, the Debian distribution used a version of OpenSSL with a key generation flaw.

This bug raises an interesting can of worms that I’m still trying to figure out.

Debian/Ubuntu servers built since 2006 need to be rekeyed.  That is a nontrivial thing, and it not going to happen in a lot of cases.  HTTPS and SSH impersonation is the first thing that leaps to mind if this vulnerability is exploited - those are very serious problems given how many systems are using those protocols for trusted path and authentication purposes.

Also, any servers relying on keys that were generated on vulnerable machines need to stop trusting those keys.  How many systems have good notes in place on where keys were generated?

It is worth noting that defense in depth works.  I have a couple of Ubuntu machines in this office right now that are probably vulnerable, but they are stored offline in a physically isolated location.  Once they are brought back online patching the vulnerability will be the first order of business.  Fortunately Linux package management functionality makes the patching process almost trivial, but it can throw a system (hypothetically) out of evaluated configuration or FIPS approved mode of operations (for example).  Nevertheless patching and rekeying is very much the correct action.

One Response to “The Debian/Ubuntu key generation flaw”

  1. Scott Shorter Says:

    I should have mentioned this earlier, but patching the systems turned out to be irritatingly NON-trivial. For some reason xubuntu patched itself, but for vanilla ubuntu I had to go hunting all over the multiverse and ultimately had to download a .deb file I found with the assistance of the great Gizoogle and a savvy colleague who had already solved the problem on Debian.

Leave a Reply