Slashdot Mirror


Aging and Bloated OpenSSL Is Purged of 2 High-Severity Bugs (arstechnica.com)

An anonymous reader cites a story on Ars Technica: Maintainers of the OpenSSL cryptographic library have patched high-severity holes that could make it possible for attackers to decrypt login credentials or execute malicious code on Web servers. The updates were released Tuesday morning for both versions 1.0.1 and 1.0.2 of OpenSSL, which a large portion of the Internet relies on to cryptographically protect sensitive Web and e-mail traffic using the transport layer security protocol. OpenSSL advisories labeled the severity of both vulnerabilities "high," meaning the updates fixing them should be installed as soon as possible. The fixes bring the latest supported versions to 1.0.1t and 1.0.2h. The decryption vulnerability is the result of what cryptographers call a padding oracle weakness, which allows attackers to repeatedly probe an encrypted payload for clues about the plaintext content inside. According to TLS expert Filippo Valsorda, the bug allows for only 16 bytes of encrypted traffic to be recovered, and even then only when an end user sends it repeatedly.

61 comments

  1. Purged, so it's no longer aged and bloated by jfdavis668 · · Score: 2

    That's a relief.

    1. Re:Purged, so it's no longer aged and bloated by Anonymous Coward · · Score: 0

      No it now also has an eating disorder. It'll eat a buffet of submissions for absurd useless additions then go to the bathroom and stick it's finger down it's throat, sad really :(

  2. CVE's by Anonymous Coward · · Score: 0

    CVE-2016-2105
    CVE-2016-2106
    CVE-2016-2107
    CVE-2016-2108
    CVE-2016-2109
    CVE-2016-2176

  3. Simple question by Anonymous Coward · · Score: 0, Insightful

    Why is OpenSSL still being used? LibreSSL is a better alternative that was forked from OpenSSL a couple of years ago. Why is OpenSSL still around?

    1. Re:Simple question by Qzukk · · Score: 1

      I use OpenSSL in an EBCDIC environment, you insensitive clod!

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    2. Re:Simple question by jandrese · · Score: 4, Informative

      A few reasons.
      1. LibreSSL has no FIPS mode. FIPS mode is kind of dumb, but it is required in some environments.
      2. LibreSSL was effectively OpenBSD only for some time. The compatibility shims have been written for other oses now I think, but it hasn't been available for as long as you think.
      3. Swapping SSL libraries is a major change, beyond what is appropriate for a point release. Conservative distros 9LTS type distros especially) will be using OpenSSL for years to come because it's too big of a change to attempt outside of a major version bump.

      --

      I read the internet for the articles.
    3. Re:Simple question by phayes · · Score: 5, Informative

      Add to those reasons the knowledge that the "better alternative" had the same undiscovered bugs and that OpenSSL found them first.

      --
      Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
    4. Re:Simple question by Anonymous Coward · · Score: 0

      A better question is why CBC mode with padding is still used. Padding to block size always struck me as a really dumb idea, considering that there are alternatives far better in every way, such as CTS and CTR.

    5. Re:Simple question by Nikademus · · Score: 1

      Those specific ones were indeed present in LibreSSL, but many others were not. Also some of the bugs, even if present, were mitigated if using OpenBSD.

      --
      I gave up with the idea of an useful sig...
    6. Re:Simple question by Rakshasa+Taisab · · Score: 2

      They say FIPS and a secure, cleanly coded ssl library can't work, so who cares about some government-mandated 'standard'.

      LibreSSL has been multi-platform for a year or so now, what are you smoking?

      Switching to LibreSSL is no more than a binary (or source) package change as it has the same ABI/API as OpenSSL except for the retarded bits.

      --
      - These characters were randomly selected.
    7. Re:Simple question by WaffleMonster · · Score: 3, Insightful

      Why is OpenSSL still being used? LibreSSL is a better alternative that was forked from OpenSSL a couple of years ago. Why is OpenSSL still around?

      Why are the majority of bug fixes flowing from OpenSSL to LibreSSL and not the other way around?

    8. Re:Simple question by zyche · · Score: 3, Informative

      While that is true to some extent, decisions taken by the LibreSSL team has
      prevented a lot of vulnerabilities.

      Notably, none of the vulnerabilities found in OpenSSL and rated "High" were applicable to LibreSSL.

    9. Re:Simple question by Junta · · Score: 3, Interesting

      The point is the flamebait title is disingenuous, as it wants to paint a picture that OpenSSL is stupid, and the heir apparent for those with that mindset is LibreSSL. Meanwhile, this specific scenario they want to hold up as evidence.... well it's no better than LibreSSL for these. Maybe the argument can be made in other ways, but here it's just bad form.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    10. Re: Simple question by Anonymous Coward · · Score: 0

      Why was it even forked in the first place? Also, because the whole "libre" name is just stupid.

    11. Re:Simple question by Anonymous Coward · · Score: 0

      They say FIPS and a secure, cleanly coded ssl library can't work, so who cares about some government-mandated 'standard'.

      LibreSSL has been multi-platform for a year or so now, what are you smoking?

      Switching to LibreSSL is no more than a binary (or source) package change as it has the same ABI/API as OpenSSL except for the retarded bits.

      Woo hoo. A whole year.

      I'll let YOU shake out the bugs...

    12. Re:Simple question by Aethedor · · Score: 1

      I don't agree with point 3. In my open source project, I changed from OpenSSL to mbed TLS in a few days.

      --
      It doesn't have to be like this. All we need to do is make sure we keep talking.
    13. Re:Simple question by rubycodez · · Score: 1

      nonsense, LibreSSL has avoided many CVE by getting rid of dangerous and bloated code. OpenSSL is indeed the choice of the uninformed and stupid, or those looking to check a government compliance box being not concerned with actual security.

    14. Re:Simple question by Copid · · Score: 1

      They say FIPS and a secure, cleanly coded ssl library can't work, so who cares about some government-mandated 'standard'.

      People who do projects for the government. On a lot of projects, it's FIPS or GTFO, which makes life miserable, but it's a fact of life.

      --
      An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
    15. Re:Simple question by Antique+Geekmeister · · Score: 2

      > LibreSSL has avoided many CVE by getting rid of dangerous and bloated code

      And discarded compatibility with many, if not most, of the platforms that OpenSSL supports.

    16. Re:Simple question by Anonymous Coward · · Score: 0

      You want to sell a product to the government? Well, guess what, you have to be FIPS *and* CC certified in most cases.

      Why? Because FIPS is basically a collection of "best practice" policies to stop the people who *think* they understand cryptography from writing code that has gigantic holes in it. Its a way of ensuring that the product/code has gone through suitable review by cryptographic experts. Is FIPS fool-proof? Of course not. Does it sometimes result in spurious assessments? Of course it does. That's the real world folks. What it is, however, is a damn-sight better than not having it.

      As for LibreSSL vs OpenSSL - I'll continue to use OpenSSL until LibreSSL has about 10 years under its belt and been used as widely as OpenSSL has been used. Why? Because field experience is invaluable and exposes issues that are not otherwise apparent. I've had code that was running in production systems for 10 years only to run into some previously unexposed bug that had been sitting there for literally years.

    17. Re:Simple question by Anonymous Coward · · Score: 0

      OpenSSL is stupid, just go read some of the code some time. It's like it was written by a 16 year old kid as a "my first big C project" with some of the brain damage present in it.

    18. Re:Simple question by serviscope_minor · · Score: 1

      And discarded compatibility with many, if not most, of the platforms that OpenSSL supports.

      Fortunately many, if not most, of those platforms have been obsolete and out of production for decades.

      --
      SJW n. One who posts facts.
    19. Re:Simple question by Anonymous Coward · · Score: 0

      LibreSSL, for obvious reasons, still uses the same API as OpenSSL - one of the most obfuscated, inconsistent and baroque API that you will ever come across.

    20. Re:Simple question by phayes · · Score: 1

      Many != all.

      --
      Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
    21. Re: Simple question by Anonymous Coward · · Score: 0

      Ummm OpenSSL has been around way longer, I'll let you shake out the bugs.

      See it works both ways.

      Old =! Secure
      New != insecure

      And vice versa.

  4. Don't hold back by halivar · · Score: 3, Insightful

    Tell us how you really feel about OpenSSL.

    1. Re:Don't hold back by Aethedor · · Score: 1

      For me, OpenSSL is irrelevant. I switched to mbed TLS (former PolarSSL) years ago. Never cared to look back.

      --
      It doesn't have to be like this. All we need to do is make sure we keep talking.
    2. Re:Don't hold back by Anonymous Coward · · Score: 0

      Wow, that is amazing. What browser are you using?

    3. Re:Don't hold back by Anonymous Coward · · Score: 0

      If you're trying to insinuate that his web browser uses OpenSSL: Mozilla doesn't. They use their own NSS library for the encryption bits.

  5. Aged by Anonymous Coward · · Score: 0

    These bits are old. Better replace them with new bits.

  6. Shocking by Anonymous Coward · · Score: 0

    Open sores lead to infections no matter how "many eyes" are looking at it. Stop living in a fantasy world.

    1. Re:Shocking by halivar · · Score: 1
  7. i've fallen and everyone's just laughing by Pseudonymous+Powers · · Score: 2

    Aging and Bloated OpenSSL Is Purged of 2 High-Severity Bugs

    The way that headline is phrased makes me want to call the Elder Abuse Hotline.

    1. Re:i've fallen and everyone's just laughing by 93+Escort+Wagon · · Score: 2

      When did OpenSSL stop beating its wife?

      --
      #DeleteChrome
  8. Truly open by Aethedor · · Score: 4, Funny

    Well, at least they've chosen the right name. It's truly open...

    --
    It doesn't have to be like this. All we need to do is make sure we keep talking.
  9. What a coincidence by WaffleMonster · · Score: 2

    "We have released LibreSSL 2.3.4, which will be arriving in the
    LibreSSL directory of your local OpenBSD mirror soon.

    This release is based on the stable OpenBSD 5.9 branch.

                    * Fix multiple vulnerabilities in libcrypto relating to ASN.1 and encoding.
                From OpenSSL."

    1. Re:What a coincidence by steveha · · Score: 1

      What a coincidence

      I'm not sure what your point is. Would you prefer that LibreSSL not acknowledge that OpenSSL found the bugs first? Are you implying that LibreSSL should have found the bugs first? Are you implying that there is no valid reason to prefer LibreSSL to OpenSSL given that LibreSSL clearly isn't perfect?

      How about if you just come right out and say what you mean, instead of making me guess?

      Looking at the history it's clear that LibreSSL has had fewer issues than OpenSSL, especially of severity "High". This looks to me like the OpenSSL guys are in fact doing some things right, and if I could choose one of the two projects to run on my systems I would choose LibreSSL. But I don't think either project can claim perfection... there were bugs in LibreSSL not in OpenSSL as well as the other way around.

      P.S. Maybe you should just switch to using libTomCrypt? I've used it, it works, and the license is entertaining. (Yes, that is the license, yes, it is not a joke, yes, the one lawyer I talked to said it seemed to be a valid license.)

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    2. Re:What a coincidence by WaffleMonster · · Score: 1

      I'm not sure what your point is. Would you prefer that LibreSSL not acknowledge that OpenSSL found the bugs first? Are you implying that LibreSSL should have found the bugs first? Are you implying that there is no valid reason to prefer LibreSSL to OpenSSL given that LibreSSL clearly isn't perfect?

      The point is they are all bad. Bragging about LibreSSL not being vulnerable to shit (In majority of instances affected feature stripped from software) is like two idiots fighting over who is smarter.

      What would have impressed me is if LibreSSL took the time up front to re-architect software to be inherently more secure. Instead what they did was function level changes, delete features THEY didn't want along with trash much of the cross platform compatibility.

      OpenSSL needs more than just a paint job. LibreSSL as yet another spinoff/competitor is something I believe benefits everyone. I do not however believe LibreSSL in its current form goes far enough to really be effective as a "secure" alternative to OpenSSL in my view.

      Looking at the history it's clear that LibreSSL has had fewer issues than OpenSSL, especially of severity "High".

      One of the largest criticisms I have of OpenSSL is they don't put enough effort into minimizing global complexity under typical usage. For example there is no reason for DTLS SRTP DOS and non-DTLS based heartbeats to have been reachable under normal use without at least explicit enablement. TLS based heartbeat as a feature does not even make logical sense. Instead of a global freakout there should have been a footnote warning few DTLS peers to upgrade because heartbeat was critically broke. There does not seem to be the needed cultural and systematic pressure to view code as a liability and take steps to hedge against it.

      The answer however is NOT to push the delete button and call it a day. I need TLS-SRP support. I need heartbeat to work as designed with DTLS. I need native compatibility with a number of platforms.

    3. Re:What a coincidence by steveha · · Score: 1

      Thank you for answering my question.

      My understanding is that LibreSSL was intended to be a drop-in replacement for OpenSSL. The LibreSSL guys grumbled a lot about some of the quirks in the OpenSSL API, but they had to implement the same API to be a drop-in replacement. Also writing this sort of software can be tricky to get right, and for all its faults OpenSSL does have a lot of stuff done right. Overall I think forking was a sane choice.

      Within the limits of my own knowledge, and what I know about OpenSSL and LibreSSL, I agree with this blog posting. And note that it is now 2016 and LibreSSL is available for Linux and other major platforms. (And it's standard on Mac OS X!)

      I do not however believe LibreSSL in its current form goes far enough to really be effective as a "secure" alternative to OpenSSL in my view.

      If you have the expertise to understand these issues, you might want to start your own project that goes further than LibreSSL. Start by making the API more sane.

      I need TLS-SRP support. I need heartbeat to work as designed with DTLS.

      I am not qualified to comment upon any of this.

      I need native compatibility with a number of platforms.

      I'm curious: what platforms are you missing from this list?

      http://www.libressl.org/releases.html

      • Linux (kernel 3.17 or later preferred)
      • FreeBSD (tested with 9.2 and later)
      • NetBSD (7.0 and later preferred)
      • HP-UX (11i)
      • Solaris (11 and later preferred)
      • Mac OS X (tested with 10.8 and later)
      • AIX (5.3 and later)
      • Microsoft Windows (XP or higher, x86 and x64)
      • Wine (32-bit and 64-bit)
      • Builds with Visual Studio 2013 or newer, Mingw-w64 and Cygwin

      P.S. I used HTML markup to get a bulleted list (the <ul> tag), but it doesn't display properly for me. Is there a trick to getting a bulleted list on Slashdot?

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
  10. Alternate title by Anonymous Coward · · Score: 0

    "OpenSSL Gets Even More Secure As Bugs Continue To Be Found And Fixed"

    Take your editorializing and arbitrary opinions and get the fuck on down the road, you little bitch

  11. Where is it? by Anonymous Coward · · Score: 0

    Where is the beautiful logo and the awe inspiring vulnerability name?

  12. The value of Open Source. by DerekLyons · · Score: 2

    "the bug was introduced in the 2013 patch"

    Yep. With Open Source, there's a lot of eyes on code and this kinda stuff doesn't happen like it does with proprietary code.

    1. Re:The value of Open Source. by Anonymous Coward · · Score: 0

      Oh, but you forgot, "you can find all those bugs yourself and fix them yourself with open source" ... assuming that you have the man-years of resources and expertise required to grok the existing code so that your changes don't break more things than they fix, and that you can convince a committer somewhere to actually listen to you...

    2. Re:The value of Open Source. by Anonymous Coward · · Score: 0

      I keep seeing people saying that.

      But fact is that it *was* found and 3 years isn't all that long. Proprietary software has (sometimes already-known) security bugs open for *decades* and is hush-hush about it.

    3. Re:The value of Open Source. by thegarbz · · Score: 1

      You're right. We fixed it in 3 years here. Now with proprietary code... well let's just say the first you'll find out about it is if someone is paid money to actively exploit it.

      Now of interest is that the issue was discovered 2 days ago and is already fixed. How fast do proprietary companies react to critical vulnerabilities? I'll tell you in 5 weeks.

    4. Re:The value of Open Source. by DerekLyons · · Score: 1

      I always laugh my ass off when the deeply religious offer prayers in response to inconvenient facts.

      Or, to put it another way, your response is completely and utterly irrelevant to my statement. That sound you heard was my point whooshing far over your head.

    5. Re:The value of Open Source. by thegarbz · · Score: 1

      I always laugh my ass off when the deeply religious offer prayers in response to inconvenient facts.

      Yeah an inconvenient fact that a bug was fixed within a day of it being noticed, when the alternate is never finding it and not knowing how long it takes to fix with no guarantee that it ever does? PRAISE THE LORD STALLMAN!!!! FOR HE IS OUR SAVIOUR!!!!

      Or, to put it another way, your response is completely and utterly irrelevant to my statement.

      *Sigh* have you tried turning your brain off and on again?

  13. Rename LibreSSl to OpenSSL by Billly+Gates · · Score: 1

    Can we get rid of this unmtained jumbled dinosaur with something more modern and actual ready for real e-commerce? Do we really need OpenVMS compability and it's own malloc() calls of LibreOSSL.

    Unfortunately, we can't just expect all the system administrators and developers, and fortune 1000 companies to leave OpenSSL. Too much red tape and client contracts dictate OpenSSL and some software is coded to break if the string doesn't say "OpenSSL".

    1. Re:Rename LibreSSl to OpenSSL by Anonymous Coward · · Score: 1

      LibreSSL had these same defects.

  14. Kill the old, in with a new by EmperorOfCanada · · Score: 1

    I don't want some backward compatable OpenSSL such as LibreSSL, I want something entirely new, something fresh and tight. The vast majority of the crypto supported by OpenSSL isn't even recommend. All kinds of crypto standards are now dead, MD5 to name just one.

    Thus I want a new easy to use library that only covers the latest and has a clear path for moving forward.

    Part of that path could be a method for abandoning various protocols/standards so that they leave the core library but are available for people to use who need backward compatibility. Simple versioning would be pretty good. UberSSL V2.x would not have everything from UberSSL V1.x and V1.x would have a end support date.

    Ideally a single project could use both with the overlapping APIs defaulting to the latest version if the functionality existed in both. In a horribly maintained project they might simultaneously incorporate V1, V2, V3, V4, ...Because they needed one old bit from each of them.

    A properly maintained project would update to the recommended crypto only found in the latest version. Effectively if it wasn't in the latest version it is probably bad security to be using it.

    That said, I still recommend a backward ability like the above because some people are forced to open old files with old protocols, and contact old embedded devices with old standards that can't be upgraded.

    1. Re:Kill the old, in with a new by Anonymous Coward · · Score: 0

      > I want something entirely new, something fresh and tight.

      And I'd like a pony to sprinkle fairy dust on me that I snort up and change gender.

    2. Re:Kill the old, in with a new by serviscope_minor · · Score: 1

      I don't want some backward compatable OpenSSL such as LibreSSL

      You can choose between GNTTLS, NSS, and a handful of others.

      I want something entirely new,

      New code = new bugs

      It also won't help with the thousands of programs written against the OpenSSL API. The libreSSL library provides a mostly compatible API, so those old programs get the benefit of new security and is providing a new API so they can be slowly migrated.

      --
      SJW n. One who posts facts.
    3. Re:Kill the old, in with a new by Anonymous Coward · · Score: 0

      I want something entirely new, something fresh and tight

      The comparison to certain human orifices actually works pretty well, as either the software product or the orifice gets older and is used constantly. Now if I can just find a way to work bleach into the analogy somewhere...

      Thus I want a new easy to use library that only covers the latest

      So it'll be incompatible with about 50% of the use cases you actually want to use it for online.

    4. Re:Kill the old, in with a new by Anonymous Coward · · Score: 0

      Thus I want a new easy to use library that only covers the latest

      but are available for people to use who need backward compatibility.

      So let's not use the old bad stuff...but let's keep using it?!

      A properly maintained project would update to the recommended crypto only found in the latest version.

      A properly maintained project

      Listen to yourself, dude. It's not all happy-path.

    5. Re:Kill the old, in with a new by mushroom+blue · · Score: 1

      > And I'd like a pony to sprinkle fairy dust on me that I snort up and change gender.

      This is probably the strangest place to announce your wish to change genders, but we of slashdot will defend to the death your right to make that decision. Good luck to you, future brother or sister.

  15. However by emil · · Score: 1

    Google says that OpenSSL currently has 437,962 lines of code, while LibreSSL is down to 316,745 as I see by wc -l $(find . -name '*.[ch]') which likely eliminates some bugs.

    LibreSSL also removes the unsafe memory management that has been roundly criticised in OpenSSL.

    LibreSSL also introduces many new features, and is generally more capable on the platforms where it runs.

    Anyone who is seriously interested in FIPS is on the NSS TLS library anyway (from Netscape/Mozilla), as it has far more certifications. OpenSSL's FIPS was actually revoked for reasons of apparent negligence, which is understandable, since it was down to two staffers at one point.

    1. Re:However by phayes · · Score: 1

      How many of those 120k lines were lopped off when LibreSSL purged all the "deemed obsolescent" platforms that would never appear in binaries for LibreSSL's "useful" platforms? 90%? 95%?

      I'm not opposed to replacing OpenSSL with LibreSSL, but the "OpenSSL is dead, everyone must move to LibreSSL" story that some are telling is false. OpenSSL started got a big shot of money & now has the ressources to audit their code, finding bugs like this one. Compare todays LibreSSL to todays OpenSSL, not the OpenSSL from 3 years ago.

      --
      Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
  16. Re:LibreSSL by Antique+Geekmeister · · Score: 2

    >> Why are the majority of bug fixes flowing from OpenSSL to LibreSSL and not the other way around?

    > Because there have hardly been any fixes in LibreSSL needed in the first place?

    Because the original LibreSSL was not to add features. It was to discard unnecessary code from the forked version of OpenSSL. Shrinking a large project by 25%, as LibraSSL seems to have done successfully, can easily solve quite a few problems, especially the complex cross-platform components. But it doesn't automatically fix _any_ of the original problems in the shared codebase.

  17. Coding standards by Anonymous Coward · · Score: 0

    What kind of secure-coding standards do all of these security projects use? Do they even have any?

    I know that it's impossible to write bug-free code, but out of all the open source projects I've seen, almost none of them seem to use any standard security-oriented boilerplate code, for reducing the dangers of e.g. memory management and other related things, in C/C++.

    The quality of code for many open source projects - including ones that are widely relied upon for being secure - is often dire. Just look at Firefox.