Technology Review’s article…
…is alarming as-is. However, there is another issue I want to point out here. Note the last paragraph of the article’s first web-page:
So how did the programmers make the mistake in the first place? Ironically, they were using an automated tool designed to catch the kinds of programming bugs that lead to security vulnerabilities. The tool, called Valgrind, discovered that the OpenSSL library was using a block of memory without initializing the memory to a known state–for example, setting the block’s contents to be all zeros. Normally, it’s a mistake to use memory without setting it to a known value. But in this case, that unknown state was being intentionally used by the OpenSSL library to help generate randomness.
I’ve never used it, but I’m sure Valgrind is a fine Open Source source code profiler. However, it is just that: A tool. It is meant to augment human work, not replace it completely. The end-result of trusting Valgrind to the extreme resulted in what appears to be a very very serious problem for many of us who use anything that uses the OpenSSL library (like SSH/SCP). Even worse, this problem has existed for two years now. And, there’s more. The patch distributed doesn’t correct the problem on systems that have deployed keys in the past two years based on the broken code. Ouch.
Tags: open source, security, tools
I vote with valgrind on this one. If you use memory in C before initialization then you violate the language specification and the program can crash (and still be considered within spec). More than that:
* regression testing is impossible with programs that can’t pass valgrind (and regression testing can be very useful)
* entropy gained by the OpenSSL method might work most of the time, but some days might not be there (for no particular reason)
* it opens a potential vector for an attacker to manipulate your random pool using input data from somewhere else
* it makes programs difficult to debug when they link to the OpenSSL library, thus programs using GnuTLS will get debugged more carefully and work better
* having something that introduces a little bit of entropy with no guarantees is a false sense of security and hides genuine problems (better to have it obviously broken)
Tel: You missed the point of the problem. The unknown state was used ON PURPOSE to help generate randomness. The issue is that blind use of automated tools can lead to problems like this one.