Drupal security update fixes a laundry list of problems, including “predictable random numbers”

The Debian Linux security team recently pushed out an wry security advisory for popular web content management system (CMS) Drupal.

As we’ve written before, CMSes and online forum software – applications that let you design, create, store, edit, backup, keep track of, and publish your website – are a popular target with cybercrooks.

After all, if a crook can get into your CMS, he can upload his own malicious downloads and booby-trapped web pages, and your server will helpfully store, organise and deliver his malware to an unsuspecting public.

You provide the brand, the reputation, the URLs and the bandwidth, and he doesn’t even have to figure out how to wrangle his dodgy content into your databases or directory structure – he can point-and-click just like you would, and the CMS will do the heavy lifting.

That lends a certain pertinence to the security summary in Debian Security Advisory DSA-2804-1, given the laundry list of fixes since the previous Drupal update back in August:

Multiple vulnerabilities have been discovered in Drupal, a fully-featured content management framework: Cross-site request forgery, insecure pseudo random number generation, code execution, incorrect security token validation and cross-site scripting.

Now THAT’s what we call a vulnerability list!

We were especially interested in the bug relating to “insecure pseudo random number generation,” since random numbers (or, more precisely, numbers that aren’t random) have been a recurring theme in recent months.

Even Linus Torvalds, the rudest man in Linuxdom, has let rip about randomness lately.

Cryptography needs good-quality random numbers, so we went looking to see what Drupal had been doing wrong and how it had fixed the problem.

Amongst other things, the old code used a PHP function called mt_rand() for generating random passwords.

The mt part stands for Mersenne Twister, a highly-regarded pseudorandom number generator for non-cryptographic purposes.

The Twister is very fast, reliably produces an unbiased stream of 32-bit integers that doesn’t repeat except on geological timescales, but it is designed for use in applications such as simulations and statistical analysis, not for cryptography.

The authors’ own website makes this abundantly clear:

In short, if you know the last few hundred random numbers produced by the Twister, you can precisely reconstruct the internal state of the generation engine – clone it, in other words – and thus work out everything that comes next.

Worse still, the Drupal code didn’t even bother to generate a decent-quality random starting seed for its Twister functions on startup, so you might even have been able to predict the initial state of the generator, and thus to predict all its outputs, not just those after you’d cloned the internal state of an already-running Twister.

Drupal’s new code uses a function that at least tries to use a cryptographic-quality random generator, drupal_random_bytes(), calling OpenSSL or reading from Unix’s /dev/urandom.

→ Under most Unix and Unix-like operating systems, /dev/urandom is a special file that can be opened and read in, just like a regular file such as a document or image. But the content is produced by a high-quality random generator running inside the kernel. Because any program that can read files can use /dev/urandom, there isn’t really any excuse for trying to invent your own source of randomness.

If you’re a Drupal user, get the update.

If you’re a Drupal coder, leave the cryptography to cryptographers.