I've become rather annoyed over the past few days about CVE-2006-5051. CVE-2006-5051 is a security flaw in OpenSSH that is described by upstream as
* Fix an unsafe signal hander reported by Mark Dowd. The signal
handler was vulnerable to a race condition that could be exploited
to perform a pre-authentication denial of service. On portable
OpenSSH, this vulnerability could theoretically lead to
pre-authentication remote code execution if GSSAPI authentication
is enabled, but the likelihood of successful exploitation appears
remote.
I requested information regarding this issue from upstream, which was ignored. Luckily Mark Dowd was kind enough to help fill me in on some of the details. What I found and how it was handled is what really has annoyed me.
Upstream claims that his issue affects GSSAPI authentication (which it doesn't) and that it's only a denial of service flaw on OpenBSD (which can't be proven). They go on to state that it may be exploitable on portable OpenSSH (which they don't know). This is a perfect example of wrong information being more dangerous than no information. Had upstream just said there was a potentially exploitable race condition being fixed, there would be far less confusion.
The fundamental issue here is that when a timeout signal handler kicks in and starts cleaning things up, it's possible the login process can continue and you end with a situation where memory can be freed twice, or possibly a use after free situation. There are three different code blocks that are executed during cleanup. One cleans up after krb5 (if enabled and being used). This is the chunk that Mark Dowd found a number of potential double free flaws. There is another block that clean up after GSSAPI. All this code does is unlink a file (which upstream seems to think is the most serious flaw). The last flaw is in the PAM cleanup. I've not researched it, nor can I say what's going on, which makes me the most worried about that particular block.
Keep in mind that I'm not claiming that this OpenSSH flaw is exploitable, I'm claiming nobody knows for sure. I admit it's not likely as this race is fairly short. I'm rather upset with upstream for their apathy on this problem. Groups such as vendor-sec are supposed to exist for peer review of such issues. Even if upstream didn't wan to get peer review they should have gotten a few team members to review the issue. The upstream advisory text leads me to believe they have no idea what the flaw really is, and their actions since publication tell me they don't care.
I was also rather disappointed today when I saw the Ubuntu OpenSSH advisory text also claims this is a denial of service issue. I fail to understand how a child daemon crashing during shutdown can be considered a denial of service security issue, especially when the only ssh clients which will see the server crash would be malicious ones (so why bother patching at all). I wonder if they are trying to weasel out of stating this could be a serious issue and they don't know, or are taking the same apathetic approach upstream is.
As the title of this post states, no information is better than wrong information, especially for security updates. My hope is other vendors handle this in the proper manner going forward.
