Page History

...

Calling a PRNG in the same initial state, either without seeding it explicitly or by seeding it with the same value, results in generating the same sequence of random numbers in different runs of the program. If Consider a PRNG function that is called 10 times consecutively seeded with some initial seed value and is consecutively called to produce a sequence of 10 random numbers without being seeded, running the code for the first time produces the sequence S = {r1, r2, r3, r4, r5, r6, r7, r8, r9, r10}. If . If the PRNG is subsequently seeded with the same initial seed value, then it will generate the same sequentce sequence S.

As a result, after the first run of an improperly seeded PRNG, an attacker can predict the sequence of random numbers that will be generated in the future runs. Improperly seeding or failing to seed the PRNG can lead to vulnerabilities, especially in security protocols.

...

Call srandom() before invoking random() to seed the random sequence generated by random(). This compliant solution produces different random number sequences each time the program is runfunction is called, depending on the resolution of the system clock:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
 
void func(void) {
  struct timespec ts;
  if (timespec_get(&ts, TIME_UTC) == 0) {
    /* Handle error */
  }
  else {
    srandom(ts.tv_nsec ^ ts.tv_sec);
    for (unsigned int i = 0; i < 10; ++i) {
      /* Generates different sequences at different runs */
      printf("%ld, ", random());
    }
  }
}

The output is as follows:

...

This may not be sufficiently random for concurrent execution, where it which may lead to correlated generated series in different threads, or for small embedded systems that have an unsigned int type with a width of 16 bits. (The POSIX standard specifies a minimum width of 32 bits for unsigned int. However, prior to the 2001 edition, POSIX.1 allowed 16 bit unsigned int).  Depending . Depending on the application and the desired level of security, a programmer may choose alternative ways to seed PRNGs. In general, hardware is more capable than software of generating real random numbers (for example, by sampling the thermal noise of a diode).

Compliant Solution (Windows)

The CryptGenRandomThe BCryptGenRandom() function  function does not run the risk of not being properly seeded because its arguments serve as seeders:

#include <stdio.h>
#include <Windows.h>
#include <wincrypt<Bcrypt.h>
#include <Ntstatus.h>
#include <stdio<Wincrypt.h>
 
void func(void) {
  HCRYPTPROV hCryptProvBCRYPT_ALG_HANDLE hAlgorithm = NULL;
  long rand_buf;
  /*PUCHAR ExamplepbBuffer of instantiating the CSP */
  if (CryptAcquireContext(&hCryptProv, NULL, NULL,= (PUCHAR) &rand_buf;
  ULONG cbBuffer                       PROV_RSA_FULL, 0)) {= sizeof(rand_buf);
  ULONG dwFlags printf("CryptAcquireContext succeeded.\n")= BCRYPT_USE_SYSTEM_PREFERRED_RNG;
  } else {
    printf("Error during CryptAcquireContext!\n")NTSTATUS status;
  }

  for (unsigned int i = 0; i < 10; ++i) {
    status if= BCryptGenRandom(!CryptGenRandom(hCryptProvhAlgorithm, sizeof(rand_buf),
  pbBuffer, cbBuffer, dwFlags);
    if (status                 (BYTE *)&rand_buf))== STATUS_SUCCESS) {
      printf("Error\n"%ld, ", rand_buf);
    } else {
      printf("%ld, ", rand_buf);/* Handle Error */
    }
  }
}

The output is as follows:

1st run: -1597837311683378946, 9061306821957231690, -13080318861933176011, 1048837407-1745403355, -931041900883473417, -658114613882992405, -1709220953169629816, -10196972891824800038, 1802206541899851668,
         406505841,1702784647, 
2nd run: 885904119-58750553, -6873795561921870721, -17822968541973269161, 14437019161512649964, -624291047673518452, 2049692692234003619, -9904515631622633366, 1312389688, -1423078042125631172, 12570792112067680022,
         897185104,
3rd run: 190598304-189899579, -15374094641220698973, 1594174739752205360, -4244019161826365616, -197515347479310867, 8269129271430950090, 1705549595-283206168, -1515331215941773185, 474951399129633665,
         1982500583,543448789, 

Risk Assessment

Automated Detection

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)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-327 and MSC32-C

• Intersection( MSC30-C, MSC32-C) = Ø

• MSC32-C says to properly seed pseudorandom number generators. For example, if you call rand(), make sure to seed it properly by calling srand() first. So far, we haven’t found any calls to rand().

• Failure to seed a PRNG causes it to produce reproducible (hence insecure) series of random numbers.

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

• Invocation of broken/risky crypto algorithms that are not properly seeded

CWE-330 and MSC32-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.

Bibliography

...

...

Image Modified Image Modified Image Modified