The numbers game

Opinion by Nick Barron

A flaw in Debian has shown that random numbers are not as random as you think. So take care when reviewing code

A flaw in Debian has shown that random numbers are not as random as you think. So take care when reviewing code.

Professor Ross Anderson has recently released the second edition of Security Engineering, a towering doorstop of a book that belongs on every security professional's bookshelf. I thoroughly recommend it, my sole criticism is that it's now so heavy that I can no longer read it while my cat sleeps on me.

Many security horror stories would be avoided if more developers read such titles. A good example is the design of random number generators for security applications. Numbers that are random enough for general use in games, spreadsheets etc are seldom good enough for security applications, so all good crypto toolkits come with a decent random number generator.

There has been a steady stream of vulnerabilities related to not-so-random numbers, from early Netscape problems with key generation to vulnerabilities in the built-in Windows random number generator. Recently, a major issue came to light with the implementation of the OpenSSL toolkit in Debian Linux. OpenSSL is a widely used toolkit that provides a comprehensive set of cryptographic functions. It's generally considered secure.

Like all good crypto toolkits, OpenSSL includes a random number generator. As well as the "disposable" session encryption keys for website transactions, OpenSSL also supports the production of public key encryption keys and web certificates. If you're viewing a website that uses SSL, there's a pretty good chance the certificate and keys were handled by OpenSSL somewhere along the line.

So what went wrong? In a code review, someone picked up an apparent bug in the OpenSSL random number generator. Using an automatic tool to scan for C-programming slip-ups, they found some code that read the value of an uninitialised variable.

Generally speaking this is a bad idea; if you read something before it has been initialised you'll get unpredictable data. This is not what you want, unless, of course, you're trying to mix some random data into a random number generator. This seeding process is essential to software "random" number generators because they're not really random. They seem to be, but if you start with the same seed data, you'll get the same stream of apparently random numbers. To get round this, you seed the generator with as much random stuff as you can find, such as mouse movement, wireless signal noise and, you guessed it, the contents of uninitialised memory.

So the offending lines were commented out, and the code checker ran without complaint. Unfortunately the result was the hobbling of the random number generator, restricting it to a range of 32,767 different streams of random numbers. That puts any random numbers generated by the broken code well within the brute force range of a modern PC. This seemingly simple bug crippled most cryptographic keys generated by many Debian applications since late 2006. See for the gory details.

The depressing thing about this whole affair is that the open-source review process is supposed to stop this from happening. Had a crypto-savvy developer looked at the change, they would have noticed immediately it was wrong. Unfortunately such a review didn't happen until May 2008 when the vulnerability surfaced. Software quality tools are like satellite navigation: blindly follow them at your peril.

It's not all bad news though. Code analysis specialists Coverty recently released a summary of their findings on a wide range of open-source projects ( The overall quality of open source is steadily improving.

The most worrying aspect is that this happened in a well established and supported product like Debian. Security-sensitive code should always be subject to careful review by developers with security expertise. Slips like this in small development teams are understandable, but this should never happen with a major OS distribution.

So if you've got people reviewing security-sensitive code, buy them a copy of Anderson's book. Make sure they read it. And if they still make stupid mistakes, drop it on their foot to teach them a lesson.

- Nick Barron is a security consultant. He can be contacted at


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events