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-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. > >
