OpenSSL fixes another severe vulnerability

OpenSSL fixes another severe vulnerability

Summary: [UPDATED] Still cleaning up after the Heartbleed debacle, OpenSSL is issuing fixes for several vulnerabilities, one of them exploitable to run arbitrary code on the client or server.

SHARE:
TOPICS: Security
17

The OpenSSL project has reported fixes for several vulnerabilities, at least one of them serious.

The most significant vulnerability is SSL/TLS MITM vulnerability (CVE-2014-0224). Unlike Heartbleed, which had been introduced into the program not long before, affects all versions of OpenSSL, including those that were patched to fix Heartbleed.

All client versions of OpenSSL are vulnerable. OpenSSL servers are only known to be vulnerable in versions 1.0.1 and 1.0.2-beta1. The bug was discovered by KIKUCHI Masashi (Lepidum Co. Ltd.) and reported to OpenSSL on May 1 via JPCERT/CC. Kikuchi has published his own explanation of the bug.

OpenSSL provides this advice:

  • OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
  • OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m
  • OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h

[UPDATE: Google's Adam Langley has written an analysis of the bug. As he notes: "... these attacks need man-in-the-middle position against the victim and that non-OpenSSL clients (IE, Firefox, Chrome on Desktop and iOS, Safari etc) aren't affected. None the less, all OpenSSL users should be updating." He adds (on Twitter) that Chrome on Android does use OpenSSL, but he has not confirmed that it is vulnerable.]

[UPDATE 2: Google has released a new version of Chrome for Android, incrementing the OpenSSL version used in it to 1.0.1h.]

The same updates fix several less-serious issues:

  • DTLS invalid fragment vulnerability (CVE-2014-0195) — A buffer overrun, potentially exploitable to run arbitrary code on the system.
  • DTLS recursion flaw (CVE-2014-0221) — Denial of service
  • SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) — Denial of service
  • SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) — Cross-section data injection or denial of service
  • Anonymous ECDH denial of service (CVE-2014-3470) — Denial of service
  • Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack (CVE-2014-0076) — Previously fixed in version 1.0.1g, this update fixes it in the 1.0.0 and 0.9.8 code branches.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

17 comments
Log in or register to join the discussion
  • I guess...

    ...many eyes have started looking at the code. About time...
    Ardwolf
  • So much for open

    Those at risk from these vulnerabilities could have just fixed the problem themselves. That's the power of open, right? #fallacy
    timacheson
    • You are assuming

      that the people using it understand how it works.

      Your average web site writer doesn't have a clue about cryptography and probably doesn't know enough C/C++ to spot the simplest of mistakes.

      OpenSSL is high math and deep cryptography, these are very complex subjects that only a handful of people around the world understand fully. That is the problem, even if it is open for all to see, if there aren't that many eyes that understand the subject, it isn't going to help much.

      You have mathematicians and cryptographers who don't understand computer code and you have coders who have never studied high level mathematics or cryptography. Neither of these groups would probably be able to find problems in the math in the code.

      Heartbleed was a relatively easy mistake to find, but you would probably have to go through reams of code you don't understand before you got to it. Most non-crypto expert programmers would have given up long before they got to that point.
      wright_is
      • Leonard, is that sarcasm?

        Yes, Sheldon, you call tell by the hashtag.
        gullbyrd
  • RE: About time...

    FOSS or not, this is how it work in the enterprise world... We won't spend too much time on stuff until a problem arise.

    Sad but true
    mack.
    • FOSS doesn't have the manpower

      The main issue that open source has is that there can be many eyes looking at the code, but without the time and full co-ordination to look at everything from the base up things slip through. There needs to be a little more time and money put into building some of these projects into something more than a glorified hobby, especially when a large portion of the web is using them.
      SalSte
      • IOW the many eyes argument isn't a benefit.

        As we said.
        ye
  • The most frightening part...

    The most frightening part perhaps is that with all these security issues in OpenSSL... what sort of vulnerabilities exist in closed-source alternatives that we simply don't or can't know about? We can actually see OpenSSL getting more and more secure. Nobody knows the state of the proprietary alternatives except its coders; they could be all but placebo for all we know.
    AnomalyTea
    • We see closed source being fixed much like we...

      ...see open source being fixed. Security disclosures and patches.
      ye
  • Off we go

    At least the OpenSSL developers aren't trying to hide the problems.
    John L. Ries
    • What a pathetic response.

      You open source fanbois sure are desperate.
      ye
    • as opposed to whom exactly

      Not sure if being unaware of a major flaw that has existed for over two years is worthy of praise. The heartbleed bug is by far the biggest fuckup in history, nothing else comes close.
      sjaak328
    • Once made aware of a vulnerability, open source is quick to patch

      Not so for Microsoft as this very recent ZDNet article showed:

      http://www.zdnet.com/after-seven-months-and-no-microsoft-patch-internet-explorer-8-vulnerability-is-revealed-7000029765/

      Microsoft' failure to patch a reported, remotely-exploitable Internet Explorer 8 vulnerability after 7 months was brought to light by HP's Tipping Point Zero-Day Initiative. Taking over 7 months to fix a remotely-exploitable vulnerability is orthogonal to any Security Development Life-cycle. Seven months equates to 7 missed opportunities to patch the vulnerability on Patch Tuesday. Not to mention an out-of-band patch during this time period.

      Sadly, one must conclude that Microsoft's SDL is not a hard requirement. One has to wonder what additional remotely-exploitable vulnerabilities Microsoft is currently sitting on.
      Rabid Howler Monkey
      • at least they are aware of it

        Not like being unaware for 2 years and then having 2 major flaws in as many months...
        aesonaus
      • You open source fanbois are pathetic.

        Trying to draw attention to others instead of acknowledging the whole "open source is more secure because people can look at the source code" was a falacy.
        ye
      • the pointing at others

        Tactic. That flaw isn't even a tenth of a percentage point as serious as heartbleed.

        Over two years, many eyes on the code, yet no one saw it. Give me a break and don't even mention the open source community for at least a few years.

        Microsoft might be sitting on a ton of vulnerabilities, but in all of my years in service, I have never seen servers leaking private keys and user data so readily and undetected as the heartbleed bug made possible. Utter utter incompetence.
        sjaak328
  • It’s open season on OpenSSL now since Heartbleed first broke

    This is precipitating more detailed scrutiny for vulnerabilities than perhaps was the case previously, with the result that the OpenSSL project yesterday announced a number of important updates to combat five new vulnerabilities. It is crucial that Android users running Google chrome should also update.

    This shows that the enterprise attack surface is always changing and even where systems were perceived safe yesterday, today they are prone to attack.

    With new vulnerabilities always being discovered, patching should always be at least a monthly exercise, if not more frequent. And of course, Security Software Configuration vulnerabilities are always being re-introduced, through bad configuration practises and mistakes made during scheduled change windows.

    Mark Kedgley, CTO, New Net Technologies
    www.nntws.com
    Mark Kedgley