OpenBSD Journal

Unknown Impact of OpenSSL Bug

Contributed by tbert on from the quickly-becoming-an-openssl-exploit-database dept.

Ted Unangst (tedu@) posted an email to tech@, entitled "not quite another erratum," concerning a bug fixed in LibreSSL:

A little background. Before we issue errata, we have to decide whether we should. That's usually pretty simple, but sometimes a bug looks exploitable when it isn't, or is exploitable when it looks benign. Clearly issuing zero errata isn't a workable solution, so we could issue errata for everything, but that leads to "patch fatigue". Instead, we pick and choose as best we are able. Sometimes that's hard.

Our primary focus is not on developing exploits. We have limited time and many other things to work on, and there is no reward for us to continue investigating exploit potential beyond a certain point.

Referring now to a specific commit by jsing, see the commit for details. The bug's existence was publicly disclosed 3 years ago; I'm not about to reveal anything particularly secret. http://marc.info/?l=openbsd-cvs&m=139913610412127&w=2

The first issue is being able to trigger a memcpy with a small negative (huge unsigned) length. In general, any memory corruption can lead to code execution, but the specifics are application dependent. It's only a problem if there's privilege escalation involved. PEM encoded certs aren't used in the TLS wire protocol, for example, so network services are not affected.

The second issue is that the incorrect handling of base64 padding will also decode to different bytes than a correct implementation. In general, any time two parsers process the same input and generate two different outputs that can lead to a security bypass, but again, the specifics are app dependent.

We looked at these issues for a while and couldn't see a means to exploit them that would justify issuing a patch, but we can't rule out that possibility either. We neither want to cry wolf nor hide the truth. Lacking a clear consensus that we should patch or not patch, what you're getting instead is this email. (I initially proposed a patch and an email saying the patch was unnecessary, but it seems less confusing to simply send the email.)

This email doesn't offer a lot of guidance about what to do, for which I apologize. At least now you know what we know.

It would probably behoove authors of software relying on LibreSSL/OpenSSL's base64 handling to audit their code to determine what, if any, impact this issue has on them.

(Comments are closed)


Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]