Thoughts on the Debian openssl vulnerability
Thursday May 15, 2008 by Derek Young
I’ve been following the Debian openssl key generation vulnerability for the last few days. It’s an interesting bug that involved a lot of different people and it’s hard to know who should take the blame.
Recap
Luciano Bello discovered that the random number generator in Debian’s patched version of openssl was not actually very random. Instead of generating one of 2^1024 values it generated only one of 2^15. All ssh keys, OpenVPN keys, and certificates generated on a Debian based system from September 2006 on are therefore weak and guessable.
Back in 2006 a Debian developer was testing openssl through valgrind and found that the library was using uninitialized memory, something which is always suspicious, especially in such a sensitive package. The developer started a discussion about this on the openssl-dev mailing list, which he believed was the proper channel to raise the issue.
Since no one on the list objected to the proposed change the patch was applied to the Debian package. Uhfortunately the attempted patch was incorrect and the flaw was introduced.
One of the openssl developers has now basically said the openssl-dev mailing list was not actually the way to raise the issue — the developers did not monitor the list.
Some of the problems:
- A package maintainer made a change to a package that he probably should not have made. He should have waited for the openssl developers to make the change.
- The openssl developers didn’t provide a way to reach them, and did not monitor the only list they published in their documentation.
- The code in question was sketchy to begin with.
Don’t rely on uninitialized memory
I’m not too surprised about the communication issues between developers on this. After all, they are all volunteers and were trying to do what they thought was best.
I am surprised that the original code was written to rely on uninitialized memory as a source of random data. Uninitialized memory is in no way random. When a process is initialized all memory given out by the kernel is zeroed out. The process does not see random data from previous processes (which would be a serious security issue) and memory does not just become random over time.
There are probably some limited cases where some pieces of process memory could become more and more random over time (maybe if you were developing a multithreaded key generation server), but even then it would be unlikely. The stack would most likely have the same pattern at the same point of execution. For a tool like ssh-keygen uninitialized memory would not be random. A compiler is always allowed to do whatever it wants with uninitialized memory and would be within its rights to zero it out or fill it was a fixed pattern.
This practice was raised years ago in a bug filed in 2003. The response to the bug was basically that using uninitialized memory is a fine thing to do and don’t ask about it again since it’s a FAQ.
The code should have been eliminated long ago to avoid legitimate confusion about its purpose.
Years ago I used valgrind on a work project and it flagged code that was calculating daylight savings time. I traced it back to its use of the current time, which had been fetched over https, which was using openssl, which was tainted by the above entropy-gathering scheme. So another reason to remove this hack is that it taints an awful lot of data unnecessarily.
— Lawrence Kesteloot May 15, 04:49 PM #