Stories
Slash Boxes
Comments

SoylentNews is people

Bug-Hunt Turns Up Vulnerability in LibreSSL

posted by janrinok on Monday October 19 2015, @11:05PM   Printer-friendly
from the found-and-fixed dept.

Arthur T Knackerbracket has found the following story:

What they've found is that there's a companion memory leak (CVE-2015-5333) and buffer overflow (CVE-2015-5334) in the SSL replacement candidate.

The researchers from Qualys (their notice published here) said they were trying to see if a remote code execution attack is feasible against vulnerabilities they've turned up in OpenSMTPD (which earlier this month hit version 5.7.3).

“Because we could not find one in OpenSMTPD itself, we started to review the malloc()s and free()s of its libraries, and eventually found a memory leak in LibreSSL's OBJ_obj2txt() function; we then realized that this function also contains a buffer overflow (an off-by-one, usually stack-based).”

The memory leak provides a path for an attacker to cause a denial-of-service attack, and also permits triggering of the buffer overflow.

The LibreSSL team has released fixes for OpenBSD.

Original Submission

 
This discussion has been archived. No new comments can be posted.
Bug-Hunt Turns Up Vulnerability in LibreSSL | Log In/Create an Account | Top | 23 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 0, Touché) by Anonymous Coward on Tuesday October 20 2015, @12:44AM

    by Anonymous Coward on Tuesday October 20 2015, @12:44AM (#252122)

    But I thought OpenBSD did thorough audits of their source code? LOL, good job guys

    Starting Score:    0  points
    Moderation   0  
       Flamebait=1, Touché=1, Total=2
    Extra 'Touché' Modifier   0  
    Total Score:   0  

  • (Score: 1, Insightful) by Anonymous Coward on Tuesday October 20 2015, @01:08AM

    by Anonymous Coward on Tuesday October 20 2015, @01:08AM (#252129)

    Yeah, the audit revealed a vulnerability, which was fixed. Looks like it all worked out.

    BTW, LibreSSL exists as a result of audited OpenSSL code.

    • (Score: 2, Informative) by Post-Nihilist on Tuesday October 20 2015, @01:40AM

      by Post-Nihilist (5672) on Tuesday October 20 2015, @01:40AM (#252135)

      The vulnerability was not exploitable, using existing code path as the stack Canary was always smashed before any exploitation could occur. It is still a vulnerability as that function could be called elsewhere in an exploitable context at some point in the future.

      --
      Be like us, be different, be a nihilist!!!

      • (Score: 3, Informative) by frojack on Tuesday October 20 2015, @04:36AM

        by frojack (1554) on Tuesday October 20 2015, @04:36AM (#252174) Journal

        It is still a vulnerability as that function could be called elsewhere in an exploitable context at some point in the future.

        Or it could be called recursively as a DOS to exhaust memory, or perhaps amass a large block of memory for some other use. I didn't see just how much memory was not freed.

        Still, matching releases to allocations is a pretty basic task for an organization that prides themselves on being secure and technically correct.

        --
        No, you are mistaken. I've always had this sig.

        • (Score: 1) by Post-Nihilist on Tuesday October 20 2015, @04:48AM

          by Post-Nihilist (5672) on Tuesday October 20 2015, @04:48AM (#252175)

          The unfreed memory could be quite large if the server was configured to accept ssl auth since only the last cert in the chain was freed

          --
          Be like us, be different, be a nihilist!!!

        • (Score: 3, Interesting) by NCommander on Tuesday October 20 2015, @08:00AM

          by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday October 20 2015, @08:00AM (#252206) Homepage Journal

          It was likely something inherited from OpenSSL rather than something they introduced. TFA isn't clear on where it came from. I just wish LibreSSL would get more traction outside the BSD community; OpenSSL is a horrid codebase.

          --
          Still always moving

          • (Score: 4, Informative) by TheRaven on Tuesday October 20 2015, @08:40AM

            by TheRaven (270) on Tuesday October 20 2015, @08:40AM (#252212) Journal
            I hope that it doesn't. It's a stop gap. There are two horrible things about OpenSSL. One is the implementation. LibreSSL is cleaning this up (though, after a massive reindent / reformat, making it annoying to compare code with OpenSSL). The other, and perhaps the more dangerous, is the API. It does evil things like tri-state return: positive value for success, zero for failure, negative for 'exceptional' failure. This is a problem because, in C, zero is false, non-zero is true, so code that does if (!some_openssl_api()) { /* error handling */ } works almost all of the time. Except when an attacker triggers the exceptional failure condition, then the code proceeds as if nothing is wrong, skipping things like certificate checks. There are many, many other ways to go wrong with OpenSSL's APIs. Clang has a few static analyser checkers for some of them, but it's by no means an exhaustive set.
            --
            sudo mod me up

            • (Score: 0) by Anonymous Coward on Tuesday October 20 2015, @06:38PM

              by Anonymous Coward on Tuesday October 20 2015, @06:38PM (#252412)

              If you use libtls instead of libssl from LibreSSL you ditch the openssl API.

    • (Score: 0, Flamebait) by Anonymous Coward on Tuesday October 20 2015, @01:47AM

      by Anonymous Coward on Tuesday October 20 2015, @01:47AM (#252138)

      Sorry about that moderation error