+8
−0
+15
−2
+15
−2
Loading
WARNING! GitLab maintenance operation scheduled for this Friday between 14:00 and 19:00 (CET). During this time window, GitLab will be unavailable, and any data entered during this period may be lost. Thank you in advance for your understanding.
The drbg's lock must be held across calls to RAND_DRBG_generate() to prevent simultaneous modification of internal state. This was observed in practice with simultaneous SSL_new() calls attempting to seed the (separate) per-SSL RAND_DRBG instances from the global rand_drbg instance; this eventually led to simultaneous calls to ctr_BCC_update() attempting to increment drbg->bltmp_pos for their respective partial final block, violating the invariant that bltmp_pos < 16. The AES operations performed in ctr_BCC_blocks() makes the race window quite easy to trigger. A value of bltmp_pos greater than 16 induces catastrophic failure in ctr_BCC_final(), with subtraction overflowing and leading to an attempt to memset() to zero a very large range, which eventually reaches an unmapped page and segfaults. Provide the needed locking in get_entropy_from_parent(), as well as fixing a similar issue in RAND_priv_bytes(). There is also an unlocked call to RAND_DRBG_generate() in ssl_randbytes(), but the requisite serialization is already guaranteed by the requirements on the application's usage of SSL objects, and no further locking is needed for correct behavior. In that case, leave a comment noting the apparent discrepancy and the reason for its safety (at present). Reviewed-by:Paul Dale <paul.dale@oracle.com> Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4328)