lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Aug 2015 15:43:59 -0400
From: Scott Arciszewski <scott@...iszewski.me>
To: dxw Security <security@....com>, fulldisclosure@...lists.org
Subject: Re: [FD] The OAuth2 Complete plugin for WordPress uses a
 pseudorandom number generator which is non-cryptographically secure
 (WordPress plugin)

On Wed, Aug 12, 2015 at 9:48 AM, dxw Security <security@....com> wrote:
> Details
> ================
> Software: OAuth2 Complete For WordPress
> Version: 3.1.3
> Homepage: http://wordpress.org/plugins/oauth2-provider/
> Advisory report: https://security.dxw.com/advisories/the-oauth2-complete-plugin-for-wordpress-uses-a-pseudorandom-number-generator-which-is-non-cryptographically-secure/
> CVE: Awaiting assignment
> CVSS: 10 (High; AV:N/AC:L/Au:N/C:C/I:C/A:C)
>
> Description
> ================
> The OAuth2 Complete plugin for WordPress uses a pseudorandom number generator which is non-cryptographically secure
>
> Vulnerability
> ================
> The following refer to the generateAccessToken() function in library/OAuth2/ResponseType/AccessToken.php, and the generateAuthorizationCode() function in library/OAuth2/ResponseType/AuthorizationCode.php.
>
> These functions attempt to generate secure auth tokens, but do not use the WordPress random number generator. Instead they use a series of fallback calculations depending on which PHP version is being used. Some of these calculations are not crypographically secure:
> The first is mcrypt_create_iv(100, MCRYPT_DEV_URANDOM). MCRYPT_DEV_URANDOM is expected to change to a different random value whenever it is called, but on Windows, on older versions of php it is known to be a constant value
> if no other functions (e.g. /dev/urandom) are available then the access token is generated solely using mt_rand(), microtime(), and uniqid().
> mt_rand() (Mersenne twister) is not a cryptographically secure pseudorandom number generator.
> According to the documentation mt_rand() is also biassed towards even return values in some circumstances.
> According to the documentation uniqid() is as secure a PRNG as microtime().
>
>
> Proof of concept
> ================
> See the documentation:
> http://www.php.net/manual/en/function.uniqid.php
> http://www.php.net/manual/en/function.mt-rand.php
>
> Mitigations
> ================
> Upgrade to version 3.1.5 or later.
> If this is not possible then ensure that you are using a recent version of php (at least 5.3), or disable the plugin.
>
> Disclosure policy
> ================
> dxw believes in responsible disclosure. Your attention is drawn to our disclosure policy: https://security.dxw.com/disclosure/
>
> Please contact us on security@....com to acknowledge this report if you received it via a third party (for example, plugins@...dpress.org) as they generally cannot communicate with us on your behalf.
>
> This vulnerability will be published if we do not receive a response to this report with 14 days.
>
> Timeline
> ================
>
> 2014-04-16: Discovered
> 2015-07-21: Reported to vendor by email
> 2015-07-21: Requested CVE
> 2015-08-10: Vendor responded
> 2015-08-11: Vendor confirmed fixed in version 3.1.5
> 2015-08-12: Published
>
>
>
> Discovered by dxw:
> ================
> Tom Adams
> Please visit security.dxw.com for more information.
>
>
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/

Hi Tom, FD readers,

> The first is mcrypt_create_iv(100, MCRYPT_DEV_URANDOM). MCRYPT_DEV_URANDOM is expected to change to a different random value whenever it is called, but on Windows, on older versions of php it is known to be a constant value

The bug you are referring to was fixed in PHP 5.3.7; this can be
solved by checking the PHP version and/or by not supporting older and
insecure versions of PHP.

See random_compat for how this should be done:

https://github.com/paragonie/random_compat/blob/master/lib/random.php#L53

> if no other functions (e.g. /dev/urandom) are available then the access token is generated solely using mt_rand(), microtime(), and uniqid().
> mt_rand() (Mersenne twister) is not a cryptographically secure pseudorandom number generator.
> According to the documentation mt_rand() is also biassed towards even return values in some circumstances.
> According to the documentation uniqid() is as secure a PRNG as microtime().

Let's quantify these numbers:

* mt_rand()
    * Predictable, only up to 31 bits of entropy in the possible seed values
    * http://www.openwall.com/php_mt_seed/
* microtime()
    * Given the UNIX timestamp of the server is generally knowable, we
can ballpark this at a maximum of 10^6 (or about 20 bits) due to
microsecond resolution.
* uniqid()
    * 10 bits of entropy by default
    * 29 bits of entropy with more_entropy
    * http://securitymaverick.com/php-uniqid-entropy-analysis-and-potentially-vulnerable-apps

So if you're using WordPress on an ancient version of PHP on Windows
or have open_basedir restrictions on Linux, and disabled ext/mcrypt,
you can squeeze 60 to 80 bits out of this, assuming all of the seeds
are unrelated.

That's not as terrible as some of what I've seen (You want me to put
this str_shuffle() password generator in production? Dream on!) but
still not great. Ideally, you want at least 100 bits of entropy (from
urandom or equivalent).

BTW, unless you're using the latest patches for 5.4, 5.5, or 5.6,
openssl_random_pseudo_bytes() can silently fail and become weak too.
:(

The lesson to learn here is that you should be running a supported
version of PHP where these bugs are fixed, rather than continuing to
run 5.2.x in 2015.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ