May 21

TSC May 21 2008 | The Right Way to Address the Debian OpenSSL Vulnerability

6  comments

It was disclosed last week that a vulnerability in the OpenSSL packages used by debian systems contained a flaw where random numbers were not actually random, paving the way for another attack vector.

Plenty of specific details and analysis can be found in different places, including:

http://wiki.debian.org/SSLkeys

http://www.us-cert.gov/cas/techalerts/TA08-137A.html

http://www.kb.cert.org/vuls/id/925211

http://secunia.com/advisories/30220/

For many, this signals the fire-drill of reaction and patching — just in time for a big holiday weekend (aka the “start of summer”) here in the United States.

Just days before this was announced, I was introduced to Venafi (as a direct result of my press pass at RSA). During the conversation, I realized they really own the niche of Systems Management for Encryption. As we shared a lively and informative conversation, I was reminded that SSL is not just something we stick on web servers; it goes deeper and wider in many enterprises today. As soon as you have to manage many of these encrypted connections, the process gains some complication – and is ripe for error. Step in Venafi.

When the debian vulnerability was announced, I immediately asked if Venafi would be willing to share some insights about how organizations should be handling this issue. This is bigger than patching (remember code red?) – and I wanted a discussion that provided insights into how to manage this in a way that brought immediate results but also good long-term gain.

During this program, Paul (from Venafi) and I start by exploring how to engage business users in the conversation. We progress to tactical and strategic ways to address this challenge while realizing this is an opportunity to make some improvements that bring better future results.

It comes from planning and following a process informed by experience – and we’ll share the insights with you in 30 minutes or less!

In the wrap-up, I suggest following the approach of plan-do-review, outlined in this podcast: http://securitycatalyst.com/blog/2008/01/31/the-security-catalyst-show-plan-do-review-your-way-to-success/

Tune in next week for the debut of the Pop Culture Security podcast – your monthly “how-to” for Security Awareness Training.


Tags

security


You may also like

Are you using frameworks properly?

Leadership and communication are actually layers, not levels

  1. Two thoughts:

    Is this mostly an academic vulnerability in many organizations? To put it another way, are many companies doing security so well that insecurely generated keys are going to get attention? Or, will they pay attention to this at the expense of something like the Help Desk using default passwords to reset accounts?

    Secondly, Ubuntu did an excellent job of handling this for me. Not only did it give me the update, but it regenerated the affected system keys for me.

    We need to continue taking this approach and apply it to things like drivers and perhaps even firmware.

  2. Two thoughts:

    Is this mostly an academic vulnerability in many organizations? To put it another way, are many companies doing security so well that insecurely generated keys are going to get attention? Or, will they pay attention to this at the expense of something like the Help Desk using default passwords to reset accounts?

    Secondly, Ubuntu did an excellent job of handling this for me. Not only did it give me the update, but it regenerated the affected system keys for me.

    We need to continue taking this approach and apply it to things like drivers and perhaps even firmware.

  3. Michael,

    To your first point: I initially thought the same thing, until I started asking around. I’m not convinced that people need to give up their holiday weekends to address this issue – but I do believe it needs to be addressed as something more than an academic exercise. However, the second part is disconcerting, since I fear it true: the time and money spent addressing this issue is likely to usurp time, money and attention from other areas.

    As to Ubuntu – good to know!

  4. Michael,

    To your first point: I initially thought the same thing, until I started asking around. I’m not convinced that people need to give up their holiday weekends to address this issue – but I do believe it needs to be addressed as something more than an academic exercise. However, the second part is disconcerting, since I fear it true: the time and money spent addressing this issue is likely to usurp time, money and attention from other areas.

    As to Ubuntu – good to know!

  5. I have also looked into this a bit more and I agree; it is a bit more serious than what I would call an “academic issue.” The brute-force space for these faulty keys is extremely small, and offline key exhaustion attacks on captured traffic is likely to be successful. I wouldn’t be surprised to see the script kiddies shifting their attack methods as a result of this flaw.

    As an interesting aside, if Debian randomizes PIDs like I believe OpenBSD does, there would have been an additional (small and almost irrelevant) countermeasure against guessing the correct key.

  6. I have also looked into this a bit more and I agree; it is a bit more serious than what I would call an “academic issue.” The brute-force space for these faulty keys is extremely small, and offline key exhaustion attacks on captured traffic is likely to be successful. I wouldn’t be surprised to see the script kiddies shifting their attack methods as a result of this flaw.

    As an interesting aside, if Debian randomizes PIDs like I believe OpenBSD does, there would have been an additional (small and almost irrelevant) countermeasure against guessing the correct key.

Comments are closed.
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!