The process which came to the conclusion below took about 15-20 hours
of accumulated developer time over the weekend. I'm almost running
out of fingers counting developers.
I wish we had the resources so that we could dedicate people to this
in a more serious way. At least if we could dedicate them for a
while, until this codebase has become wittled down. But we don't.
Yes, that is a hint. It could be like the KMS effort over the last
two years. Lacking that, this situation below is going to repeat
itself again.
Actually, it will repeat itself tomorrow
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-cvsm=139913610412127w=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.
