Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Become a Partner and License Our Database or Notification Service
OpenSSL Uses Potentially Predictable Pseudo-Random Number Generator
SecurityTracker Alert ID: 1001961|
SecurityTracker URL: http://securitytracker.com/id/1001961
(Links to External Site)
Date: Jul 10 2001
Disclosure of authentication information|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): up to 0.9.6a|
OpenSSL announced a vulnerability in the cryptographic toolkit's pseudo-random number generator (PRNG) that could allow an attacker to predict future PRNG output.|
The pseudo-random number generator (PRNG) in SSLeay/OpenSSL reportedly contains a design error that weakens the function such that it could become predictable.
The PRNG function (source code file crypto/md_rand.c) uses a hash function to update its internal secret state and to generate output. The secret state consists of two items: 1) a chaining variable message digest 'md' that is the output of the hash function, and 2) a large buffer variable 'state' that is is accessed circularly and used for storing additional entropy.
When generating output bytes, vulnerable versions of OpenSSL set the 'md' variable to the hash of one half of its previous value (which is also the same half that was used as PRNG output, meaning that it is not a secret value) and some other data, including bytes from 'state'. In addition, the number of bytes used from 'state' depended on the number of bytes requested as PRNG output and could be as small as one, making a brute-force analysis of all possible cases feasible.
These two design flaws make it possible to reconstruct the complete internal PRNG state from the output of one large PRNG request (large enough gain knowledge on the 'md' variable) followed by enough consecutive 1-byte PRNG requests to cycle through all of 'state'.
A user could potentially determine future PRNG output, which could lead to an attack of the system using the PRNG output.|
An updated version is available and a patch for current versions is also available. The vendor strong recommends using the updated version. See the Vendor URL for the update.|
Vendor URL: www.openssl.org/ (Links to External Site)
Linux (Any), UNIX (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Date: Tue, 10 Jul 2001 13:03:17 +0200|
Subject: OpenSSL Security Advisory: PRNG weakness in versions up to 0.9.6a
OpenSSL Security Advisory [10 July 2001]
WEAKNESS OF THE OpenSSL PRNG IN VERSIONS UP TO OpenSSL 0.9.6a
- Detailed problem description
- Source code patch [*]
[*] OpenSSL 0.9.6b has been corrected and does not require this patch.
The source code of OpenSSL 0.9.6b is available as file openssl-0.9.6b.tar.gz
from <URL: ftp://ftp.openssl.org/source;type=d>.
If you were previously using the "engine" release of OpenSSL 0.9.6 or
0.9.6a, obtain file openssl-engine-0.9.6b.tar.gz instead.
OpenSSL source code can also be obtained from a number of mirror sites.
For a list, see <URL: http://www.openssl.org/source/mirror.html>.
If you are using a pre-compiled OpenSSL package, please look for update
information from the respective software distributor. The OpenSSL
group itself does not distribute OpenSSL binaries.
The pseudo-random number generator (PRNG) in SSLeay/OpenSSL versions
up to 0.9.6a is weakened by a design error. Knowing the output of
specific PRNG requests (including a number of consecutive very short
PRNG requests) would allow an attacker to determine the PRNG's
internal state and thus to predict future PRNG output.
Typical applications (including applications using OpenSSL's SSL/TLS
library) are not vulnerable to this attack because PRNG requests
usually happen in larger chunks. However, we strongly recommend
upgrading to OpenSSL 0.9.6b, which includes a fixed PRNG.
If upgrading to 0.9.6b is not immediately possible, the source
code patch contained at the end of this advisory should be applied.
DETAILED PROBLEM DESCRIPTION
Recently a cryptographic flaw in OpenSSL's built-in pseudo-random
number generator (PRNG) was pointed out to us by Markku-Juhani
O. Saarinen <firstname.lastname@example.org>, who showed how
an attacker could reconstruct the PRNG's internal state from
the output of a couple of hundred 1-byte PRNG requests. This problem
dates back to SSLeay, which OpenSSL is based on, and was found in other
SSLeay-based toolkits as well. While a number of enhancements have
been done to the original PRNG during the development of OpenSSL, this
design error was overlooked so far.
The PRNG (implemented in source code file crypto/md_rand.c) uses a
hash function, by default SHA-1, to update its internal secret state
and to generate output. The secret state consists of two components:
A chaining variable 'md', sized according to the hash function's
output (160 bits for SHA-1), and a large buffer 'state'. 'md' is
always replaced by a hash function output during the PRNG's operation.
'state' is accessed circularly and is used for storing additional
When generating output bytes, OpenSSL versions up to 0.9.6a set 'md'
to the hash of one half of its previous value and some other data,
including bytes from 'state'. The design error was that the half of
'md' input to the hash function was the same half that was also used
as PRNG output, meaning that it in general cannot be considered
secret. Also the number of bytes used from 'state' depended on the
number of bytes requested as PRNG output and could be as small as one,
allowing for easy brute-force analysis of all possible cases.
The combination of these effects made it possible to reconstruct
the complete internal PRNG state from the output of one PRNG request
appropriately sized to gain knowledge on 'md' followed by enough
consecutive 1-byte PRNG requests to traverse all of 'state'.
OpenSSL 0.9.6b changes the PRNG implementation as follows to give the
PRNG its intended strength:
1. When updating 'md' during PRNG output generation, all of the
previous 'md' value is hashed, including the secret half.
2. Also, the number of bytes from 'state' included into the hash is
now independent from the number of PRNG bytes requested.
The first measure alone would be sufficient to solve the problem. The
second measure makes sure that additional data from 'state' is never
mixed in in small portions; this heuristically further strengthens the
It is unlikely for applications to request PRNG bytes in a pattern
allowing for the attack against the OpenSSL PRNG. Typically,
applications will request PRNG bytes in larger chunks.
No applications is known to us which is actually vulnerable.
However, the PRNG design flaw is a significant weakness: The PRNG does
not provide the intended strength under all circumstances. Therefore,
we strongly recommend that all users upgrade to OpenSSL 0.9.6b as soon
SOURCE CODE PATCH
If upgrading to OpenSSL 0.9.6b is not immediately possible, the
following patch should be applied to file crypto/rand/md_rand.c in the
OpenSSL source code tree. (The patch is compatible with OpenSSL
versions 0.9.5 up to 0.9.6a.) This changes the PRNG in two ways, as
@@ -313,6 +313,7 @@
static volatile int stirred_pool = 0;
+ int num_ceil;
unsigned char local_md[MD_DIGEST_LENGTH];
@@ -333,6 +334,12 @@
+ if (num <= 0)
+ return 1;
+ /* round upwards to multiple of MD_DIGEST_LENGTH/2 */
+ num_ceil = (1 + (num-1)/(MD_DIGEST_LENGTH/2)) * (MD_DIGEST_LENGTH/2);
* (Based on the rand(3) manpage:)
@@ -418,11 +425,11 @@
md_c = md_count;
memcpy(local_md, md, sizeof md);
if (state_index > state_num)
state_index %= state_num;
- /* state[st_idx], ..., state[(st_idx + num - 1) % st_num]
+ /* state[st_idx], ..., state[(st_idx + num_ceil - 1) % st_num]
* are now ours (but other threads may use them too) */
md_count += 1;
@@ -434,6 +441,7 @@
while (num > 0)
+ /* num_ceil -= MD_DIGEST_LENGTH/2 */
j=(num >= MD_DIGEST_LENGTH/2)?MD_DIGEST_LENGTH/2:num;
@@ -444,27 +452,28 @@
curr_pid = 0;
MD_Update(&m,(unsigned char *)&(md_c),sizeof(md_c));
MD_Update(&m,buf,j); /* purify complains */
if (k > 0)
- for (i=0; i<j; i++)
+ for (i=0; i<MD_DIGEST_LENGTH/2; i++)
state[st_idx++]^=local_md[i]; /* may compete with other threads */
if (st_idx >= st_num)
+ if (i < j)
*** END OF PATCH ***
We thank Markku-Juhani O. Saarinen <email@example.com>
for discovering the PRNG problem and bringing it to our attention.
URL for this Security Advisory:
Go to the Top of This SecurityTracker Archive Page