I really wanted to abstain from commenting the Debian OpenSSL disaster. I have however read far to many false claims and bloodcurtling comments to leave them uncommented.
Clearly, the Debian's OpenSSL maintainer has messed up seriously. Very seriously. He is the one to blame for thousands of machines being easily attackable during a time period of about 2 years.
It's not as if the OpenSSL team was unblamable of this misery though.
- The original query of the Debian Developer resulted in an unfortunate answer of an OpenSSL team member, and other than that ignorance. Another mail about a year later clearly says that a patch commenting out those lines made it into Debian, again with no feedback, so even the "If OpenSSL had known that this should go into Debian..." argument is invalid. I wonder why, since an OpenSSL guy claims that this mistake is so obvious and that upon seeing the patch, "we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was."
I am not going to comment on the the claim that openssl-dev was the wrong mailing list, as Branden's blog post leaves nothing to add on that topic. - The claim that making OpenSSL Valgrind-clean is just a minor, unimportant cosmetic fix is wrong. The OpenSSL library is typically used by programs with network access. The developers of these programs often use Valgrind to catch memory access failures, which could easily compromise the security of the machine if not detected. Being able to Valgrind your code without drowning in OpenSSL warnings and errors is an important thing.
Using very questionable (see point below) constructs in the code without even a source code comment is not something to be proud of either.
- The claim that the original OpenSSL code is not buggy is wrong. The claim that the "harmless" part of the disastrous patch is just harmless is wrong. It fixes a serious bug in OpenSSL. Using uninitialised objects with allocated or automatic storage results in undefined behavior in C.
It may add Entropy to the pool. It may crash. It may send out a tarball of your .ssh and .gnupg directories to ronald@mcdonald.com without letting you know.
All three options (and any other option) is completely valid at program run time, or even at compile time.
For example, this is a program that I use to predict the lottery numbers of the next five years:
#include <stdio.h>
int main()
{
int a;
a++;
printf("%d\n",a);
return 0;
}
What? This doesn't work for you? Welcome to the wonderful world of undefined behavior.
In the light of this, above linked comments sound almost ironic.
I feel Debian has learnt a lesson out of this. Can the OpenSSL team say the same?
Disclaimer: These are solely my oppinions. I speak for no project or company or whatever. I am in no way affiliated to either OpenSSL or Debian. Both are outstanding, impressive free software projects.
Agreed on all of the above, I've written a bit of an article myself but I feel I should put about the general points as widely as possible.
ReplyDelete* OpenSSL is a library, and libraries are expected to cooperate with application code, breaking debugging tools is not good.
* The worst case for entropy in uninitialised memory is no entropy at all, and (thanks to minimax) you must base your design around the worst case. Thus the security benefits of such an entropy source must be regarded as zero.
* Worse than making a mistake is hiding a mistake. Using PID to provide entropy does not deliver any security benefit, but does make bugs like the debian bug harder to detect.
* Regression testing is impossible on programs that fail the valgrind test. Regression testing is an important tool for preventing bugs creeping in due to code maintenance.
* Code should be readable and understandable as widely as possible. Doing "clever" special things with no comments is an accident waiting to happen.
* A false sense of security is worse than no security at all. Weak entropy sources are dangerous for this reason.
* Uninitialised buffers might really be copies of input from far away (possibly a distant parent process) put there by a systematic attacker. Your entropy pool could be manipulated.
hola
ReplyDelete