# MSC30-C. Do not use the rand() function for generating pseudorandom numbers

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 `rand()` 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 can be predictable. 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 };

void func(void) {
/*
* id will hold the ID, starting with the characters
*  "ID" followed by a random integer.
*/
char id[len];
int r;
int num;
/* ... */
r = rand();  /* Generate a random integer */
num = snprintf(id, len, "ID%-d", r);  /* Generate the ID */
/* ... */
}```

## Compliant Solution (POSIX)

This compliant solution replaces the `rand()` function with the POSIX `random()` function:

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

enum { len = 12 };

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

The POSIX `random()` function 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 usable. The `rand48` family of functions provides another alternative for pseudorandom numbers.

Although not specified by POSIX, `arc4random()` is another possibility for systems that support it. The `arc4random(3)` manual page [OpenBSD] states

... provides higher quality of data than those 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 `BCryptGenRandom()` function can be used to generate cryptographically strong random numbers. The Microsoft Developer Network `BCryptGenRandom()` reference [MSDN] states:

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.h>

#pragma comment(lib, "Bcrypt")

void func(void) {
BCRYPT_ALG_HANDLE Prov;
int Buffer;
if (!BCRYPT_SUCCESS(
BCryptOpenAlgorithmProvider(&Prov, BCRYPT_RNG_ALGORITHM,
NULL, 0))) {
/* handle error */
}
if (!BCRYPT_SUCCESS(BCryptGenRandom(Prov, (PUCHAR) (&Buffer),
sizeof(Buffer), 0))) {
/* handle error */
}
printf("Random number: %d\n", Buffer);
BCryptCloseAlgorithmProvider(Prov, 0);
}```

## Risk Assessment

The use of the `rand()` function can result in predictable random numbers.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MSC30-C

Medium

Unlikely

Low

P6

L2

### Automated Detection

Tool

Version

Checker

Description

Astrée
24.04
stdlib-use-randFully checked
Axivion Bauhaus Suite

7.2.0

CertC-MSC30
Clang
4.0 (prerelease)
`cert-msc30-c`Checked by `clang-tidy`
CodeSonar
8.1p0
Compass/ROSE

Coverity
2017.07

DONTCALL

Implemented - weak support

ECLAIR

1.2

CC2.MSC30

Fully implemented

Helix QAC

2024.1

C5022

C++5029

Klocwork
2024.1

CERT.MSC.STD_RAND_CALL

LDRA tool suite
9.7.1
44 SEnhanced enforcement
Parasoft C/C++test
2023.1

CERT_C-MSC30-a

Do not use the rand() function for generating pseudorandom numbers
PC-lint Plus

1.4

586

Fully supported

Polyspace Bug Finder

R2024a

CERT C: Rule MSC30-CChecks for vulnerable pseudo-random number generator (rule fully covered)

RuleChecker

24.04

stdlib-use-randFully checked

### Related Vulnerabilities

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

## Related Guidelines

Key here (explains table format and definitions)

Taxonomy

Taxonomy item

Relationship

CERT CMSC50-CPP. Do not use std::rand() for generating pseudorandom numbersPrior to 2018-01-12: CERT: Unspecified Relationship
CERT Oracle Secure Coding Standard for JavaMSC02-J. Generate strong random numbersPrior to 2018-01-12: CERT: Unspecified Relationship
CWE 2.11CWE-327, Use of a Broken or Risky Cryptographic Algorithm2017-05-16: CERT: Rule subset of CWE
CWE 2.11CWE-330, Use of Insufficiently Random Values2017-06-28: CERT: Rule subset of CWE
CWE 2.11CWE-338, Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)2017-06-28: CERT: Rule subset of CWE
CWE 2.11CWE-6762017-05-18: CERT: Rule subset of CWE

## 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

1. The compliant solution purportedly using that rand48 family of functions doesn't use any of them.

2. I think that the POSIX compliant solution would be better if it checked whether time(0) returned (time_t)-1 or not.  This would better adhere to the earlier recommendation to check return values for errors.  Otherwise, if an error occurs, an attacker could seed the random() function with -1 to determine the random numbers generated.

1. Changed code to check for this. Also s/0/NULL/;

Not sure the check is necessary...my linux manpage sez time(2) only returns an error if the argument pointer is invalid. But just to be safe...

3. Wietse Venema sez:

The (POSIX) compliant solution uses srandom(time(0)) for initialization,
but fails to mention that this makes the result of random() predictable.

The text should better distinguish between "random" (i.e. unpredictable)
and "pseudorandom". In the best case, current computers can produce
"pseudorandom" numbers but not "random" numbers".

4. Under compliant solution (POSIX), "While the low dozen bits generated by `rand()` go through a cyclic pattern, all the bits generated by `random()` are usable." should be removed.  rand() can be a high-quality generator, but that's not mandated.  (In fact, POSIX mandated the medium-quality example shown in the C standard; instead of having a separate random() they could have required rand() to be better.)

There should be advice to the effect: "High-quality design of pseudo-random number generators or cryptographic primitives requires an unusual degree of expertise, so you should generally adopt a proven implementation rather than trying to craft your own."

5. Why is the remediation cost here "high"? s/rand/random/ is a quick automatic fix... this should be a cost of "low"

1. Maybe medium if you want to change it to the Windows one...? I agree it shouldn't be high.

6. remediation cost is now 'low'.

7. Microsoft marked CryptGenRandom as deprecated (replaced by BCryptGenRandom):

https://docs.microsoft.com/en-us/windows/desktop/api/wincrypt/nf-wincrypt-cryptgenrandom

And something else that i noticed:

Coverity marks random() as risky (but still recommends using the now deprecated CryptGenRandom()):

"Calling risky function (DC.WEAK_CRYPTO)dont_call: random should not be used for security related applications, as linear congruential algorithms are too easy to break.

Use a compliant random number generator, such as /dev/random or /dev/urandom on Unix-like systems, and CryptGenRandom on Windows."

Not really wrong or so but maybe interesting.

1. Are you sure BCryptGenRandom is current? From MSDN's page, this function is only supported in Vista and Server 2008. Which aren't exactly modern OS's.
https://docs.microsoft.com/en-us/windows/desktop/api/Bcrypt/nf-bcrypt-bcryptgenrandom

1. MSDN is documenting when those APIs were introduced; BCryptGenRandom() is current.

1. With Aaron Ballman's help, I have replaced the CryptGenRandom() solution with a BCryptGenRandom() solution.