Page History

Pseudorandom number generators use mathematical algorithms to produce a sequence of numbers with good statistical properties, but the numbers produced are not genuinely random.

The C Standard function rand() (available in stdlib.h) does not have good random number properties function makes no guarantees as to the quality of the random sequence produced. The numbers generated by some implementations of rand() have a comparatively short cycle , and the numbers may can be predictable.

To achieve the best random numbers possible, an implementation-specific function must be used. When unpredictability really matters and speed is not an issue, such as in the creation of strong cryptographic keys, use a true entropy source such as /dev/random or a hardware device capable of generating random numbers. The /dev/random device may block for a long time if there are not enough events going on to generate sufficient entropy. From the Linux urandom(4) manual page:

A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.

In many cases, however, it will be acceptable to simply use a pseudorandom number generator from a cryptographic library (such as the Mersenne Twister) and seed it with data read from /dev/random.

 Applications that have strong pseudorandom number requirements must use a generator that is known to be sufficient for their needs.

Noncompliant

...

Code Example

The following noncompliant code generates an ID with a numeric part produced by calling the rand() function. The IDs produced are predictable and have limited randomness.

#include <stdio.h>
#include <stdlib.h>
 
enum { len = 12 };
char id[len];
 
void func(void) {
  /*
   * id will hold the ID, starting with the characters "ID" */
   *  "ID" followed by a random integer.
     */*
  followed by a random integer */
char id[len];  
  int r;
  int num;
  /* ... */
  r = rand();  /* generateGenerate a random integer */
  num = snprintf(id, len, "ID%-d", r);  /* generateGenerate the ID */
  /* ... */
}

Non-Compliant Code Example

Compliant Solution (POSIX)

This compliant solution replaces the rand() function with the POSIX A better pseudorandom number generator is the random() function.:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>


enum { len = 12 };
char id[len]; 

void func(void) {
  /*
   * id will hold the ID, starting with the characters "ID" */
   *  "ID" followed by a random integer.
     */*
  followed by a random integer */
char id[len];  
  int r;
  int num;
  /* ... */
srandom(time(0)  struct timespec ts;
  if (timespec_get(&ts, TIME_UTC) == 0) {
    /* Handle error */
  }
  srandom(ts.tv_nsec ^ ts.tv_sec);  /* seedSeed the PRNG with the current time */
  /* ... */
  r = random();  /* generateGenerate a random integer */
  num = snprintf(id, len, "ID%-d", r);  /* generateGenerate the ID */
  /* ... */
}

The POSIX However, the instance of the random() function in this example uses time(0) as a seed. With a trivial seed like time(0), the results from is a better pseudorandom number generator. Although on some platforms the low dozen bits generated by rand() go through a cyclic pattern, all the bits generated by random() are also predictable.

Compliant Solution (POSIX)

long int li;
FILE* fd;

if(!(fd = fopen("/dev/random", "r")) {
   /* Handle error condition */
}

if(fread(&li, sizeof(li), 1, fd) != sizeof(li)) {
   /* Handle error condition */
}

fclose(fd);

printf("Random number: %ld\n", li);

usable. The rand48 family of functions provides another alternative for pseudorandom numbers.

Although not specified by POSIX, arc4random() is an option on another possibility for systems that support it. From the The arc4random(3) manual page :[OpenBSD] states

... provides higher quality of data than those arc4random() fits into a middle ground not covered by other subsystems such as the strong, slow, and resource expensive random devices described in random(4) versus the fast but poor quality interfaces described in rand(3), random(3), and drand48(3).

To achieve the best random numbers possible, an implementation-specific function must be used. When unpredictability is crucial and speed is not an issue, as in the creation of strong cryptographic keys, use a true entropy source, such as /dev/random, or a hardware device capable of generating random numbers. The /dev/random device can block for a long time if there are not enough events going on to generate sufficient entropy.

Compliant Solution (Windows)

On Windows platforms, the CryptGenRandom BCryptGenRandom() function may can be used to generate cryptographically strong random numbers. It is important to note, however, that the exact details of the implementation are unknown, and it is undetermined as to what source of entropy the CryptGenRandom() uses. From the The Microsoft Developer Network CryptGenRandomBCryptGenRandom() reference [MSDN] states:

If an application has access to a good random source, it can fill the pbBuffer buffer with some random data before calling CryptGenRandom(). The CSP then uses this data to further randomize its internal seed. It is acceptable to omit the step of initializing the pbBuffer buffer before calling CryptGenRandom()The default random number provider implements an algorithm for generating random numbers that complies with the NIST SP800-90 standard, specifically the CTR_DRBG portion of that standard.

#include <Windows.h>
#include <bcrypt.h>
#include <stdio
#include<Wincrypt.h>

HCRYPTPROV hCryptProv;
union {#pragma comment(lib, "Bcrypt")

void func(void) {
  BCRYPT_ALG_HANDLE Prov;
  int Buffer;
  if (!BCRYPT_SUCCESS(
    BYTE bs[sizeof(long int)];      BCryptOpenAlgorithmProvider(&Prov, BCRYPT_RNG_ALGORITHM,
                                      NULL, 0))) {
    long int li;
} rand_buf;

if(!CryptGenRandom(hCryptProv, sizeof(rand_buf), &rand_buf/* handle error */
  }
  if (!BCRYPT_SUCCESS(BCryptGenRandom(Prov, (PUCHAR) (&Buffer),
                                      sizeof(Buffer), 0))) {
    /* Handlehandle error */
} else {}
    printf("Random number: %ld%d\n", Buffer);
  BCryptCloseAlgorithmProvider(Prov, rand_buf.li0);
}

Risk Assessment

Using The use of the rand() function leads to possibly can result in predictable random numbers.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 7.20.2.1, "The rand function"

Related Guidelines

Key here (explains table format and definitions)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-327 and MSC30-C

• CWE-327 forbids “broken or risky cryptographic algorithms” but does not specify what constitutes such an algo.

• Per CERT judgement, rand() qualifies, so:

• CWE-327 = Union( MSC30-C, list) where list =

• Invocation of broken/risky crypto algorithms besides rand()

CWE-338 and MSC30-C

CWE-338 = Union( MSC30-C, list) where list =

• Use of a weak PRNG besides standard C rand().

CWE-330 and MSC30-C

Independent( MSC30-C, MSC32-C, CON33-C)

CWE-330 = Union( MSC30-C, MSC32-C, CON33-C, list) where list = other improper use or creation of random values. (EG the would qualify)

MSC30-C, MSC32-C and CON33-C are independent, they have no intersections. They each specify distinct errors regarding PRNGs.

CWE-676 and MSC30-C

• Independent( ENV33-C, CON33-C, STR31-C, EXP33-C, MSC30-C, ERR34-C)

• MSC30-C implies that rand() is dangerous.

• CWE-676 = Union( MSC30-C, list) where list =

• Invocation of other dangerous functions, besides rand().

Bibliography

...

Image Added Image Added Image AddedMSC13-A. Detect and remove unused values      14. Miscellaneous (MSC)       MSC31-C. Ensure that return values are compared against the proper type