Critical security update: Version 0.26.7 Beta

 Mokuji developer Posted

The latest beta version comes with a critical security update. We recommend everyone to update their installations as soon as possible. This post explains the vulnerability and how it's fixed.

tl;dr version

The generator for random data was broken and unsafe unless you had direct /dev/urandom access using fopen(). This new version fixes that by adding more sources of random data and improving the existing ones.

What was wrong?

Mokuji used two alternative sources to generate random characters. The first was /dev/urandom which is only available on Unix servers. And the second was a custom generator based on microtime() and mt_rand().

While the first is considered safe, the second should be a last resort. We noticed though that many server environments did not provide direct access to /dev/urandom (usually due to an open_basedir restriction). Meaning that the "last resort" option was used a lot.

On top of this the "last resort" implementation turned out to have a bug, where certain ranges of requested bits would not output enough data as a response or sometimes even no data at all. as was the case with the 24 requested characters for the "remember me"-cookies.

How is it resolved?

1. New sources of random data have been implemented.

In order of priority:

  1. /dev/urandom using the Mcrypt module. This fixes the open_basedir problems IF the Mcrypt module is installed on your server.
  2. /dev/urandom using the fopen() function. This is the same implementation as was used before this update as the main source.
  3. openssl_random_pseudo_bytes. A new alternative source that utilizes multiple sources of random data. Requires your PHP version to be compiled with OpenSSL.
  4. CAPICOM.Utilities::GetRandom. A source of random data provided by older Windows servers. Similar to /dev/urandom but not as strong. Meaning other sources deserve priority.
  5. A newly implemented "last resort" algorithm.

This larger list of alternatives improves the odds that your server will have a stronger source of random bits available by default.

2. A new "last resort" algorithm.

The previous "last resort" algorithm had several problems. It had bugs that sometimes made it fail, it was slow and it had very weak sources of entropy.

The new algorithm collects more entropy by using request data from visitors and maintaining an internal state. On top of this, the implementing code is a lot faster and more simple, meaning that it's a lot less likely to attract any bugs.

3. Security verification.

In the administrator panel you can now verify which source was last used for collecting random data. Based on this you can judge whether your application requires changes to your server, like installing the Mcrypt module. You can find it in the Security Settings section.

Security verification

How bad was this vulnerability?

For the majority of uses there were no serious problems. However one particular function was vulnerable to attacks. The "remember me" functionality would output predictable cookies when /dev/urandom was not available. Meaning you could log in if you knew a user ID that uses the "remember me" function.

Other than this function, it was possible to create a non-trivial attack trying to predict the random data output. In the worst case this could be used to exploit the "password forgotten" functionality.

To our knowledge however, no attacks of either sort have been executed.

Replies