Stories
Slash Boxes
Comments

SoylentNews is people

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

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.
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: 2) by engblom on Tuesday October 20 2015, @09:33AM

    by engblom (556) on Tuesday October 20 2015, @09:33AM (#252221)

    C coders who insist that all variables need to be declared at the top of the function they're used in are the problem. If they'd have gone straight to using a more local scope for that pointer, the memory would not have leaked, and the buffer overflow would have become impossible. Learning to use scope sensibly is not hard. In fact it's trivial. It's just as easy to teach people to use the smallest scope possible as it is to teach them to use the largest-but-one scope possible. C doesn't need fixing, it's just that plenty of C coders need fixing. But plenty of coders in most languages need fixing, this doesn't make C any worse than any other language.

    (But in other news - Digital Mars D is the better C that all of the other better C's wish they were.)

    First, the OpenBSD coders are not needed to get "fixed". They are already very skilled. Still they do mistakes because it is human to err. C allows a whole class of mistakes that comes only from the manual memory management. Most of the vulnerabilities reaching the news is because of mistakes because of C's memory management and not even the most skilled programmers are immune against failing.

    Second, in many cases it is not about the scope as you often pass around pointers to whatever data structure you are using. The error is because of where the declaration is done, but in checking you stay inside of the memory area you should when you use the data structure the pointer pointed at.

    The mistake in the article was a off-by-one error. Most modern languages makes a program to crash if you are off-by-one. With C you are in a more dangerous situation.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by engblom on Tuesday October 20 2015, @09:35AM

    by engblom (556) on Tuesday October 20 2015, @09:35AM (#252222)

    The error is because of where the declaration is done, but in checking you stay inside of the memory area you should when you use the data structure the pointer pointed at.

    I meant:

    The error is not in where the declaration is done, but in checking you stay inside of the memory area you should when you use the data structure the pointer pointed at.

  • (Score: 0) by Anonymous Coward on Tuesday October 20 2015, @10:58AM

    by Anonymous Coward on Tuesday October 20 2015, @10:58AM (#252238)

    >The mistake in the article was a off-by-one error. Most modern languages makes a program to crash if you are off-by-one. With C you are in a more dangerous situation.

    Which is readily solved by a custom allocator. A multitude of projects go that route.
    But in this specific case I agree with the sentiment. C is obviously too hard for humans such that do a "snprintf(buf, buf_len, ".%s", bndec)". :-)

    • (Score: 2) by LoRdTAW on Tuesday October 20 2015, @01:25PM

      by LoRdTAW (3755) on Tuesday October 20 2015, @01:25PM (#252279) Journal

      C is obviously too hard for humans such that do a "snprintf(buf, buf_len, ".%s", bndec)". :-)

      I think we can blame the C libraries for this.