Contrib.social

Crypt::randomBytes()/drupal_random_bytes() doesn't actually return cryptographically secure random bytes

Open on Drupal.org →
Created on 13 August 2015, over 9 years ago
Updated 11 June 2023, over 1 year ago

Problem/Motivation

Drupal prefers openssl_random_pseudo_bytes() if available in Crypt::randomBytes() in 8.0.x or drupal_random_bytes() in 7.x and 6.x.

PHP used the wrong method in the openssl library now fixed in 5.6.12, 5.5.28, 5.4.44 see: https://bugs.php.net/bug.php?id=70014 but it is NOT classified as a security hole so backports are to older (ie distro) versions are less likely. Just because PHP didn't declare this a security hole doesn't mean it is not. But also read on for other scenarios where this class creates a security hole.

The returned pseudo-random bytes were NOT necessarily cryptographically secure.

Proposed resolution

Add random_compat v2.0.2 to core + use it for Crypt::randomBytes()
Adding v2 should be ok here because in drupal 7.x this includes a fallback.
(so not a concern like in #2763787: Upgrade random_compat to latest version → which reverted the upgrade to v2.0.2 in drupal 8.2.x and 8.3.x)

Remaining tasks

review

User interface changes

n/a

API changes

n/a

Data model changes

n/a

RC phase evaluation

🐛 Bug report
Status

Fixed

Version

7.0 ⚰️

Component
Base  →

Last updated about 7 hours ago

Created by

🇺🇸United States pwolanin

Live updates comments and jobs are added and updated live.
  • Security

    It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.

  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024