Lack of CSPRNG Threatens WordPress Sites | Hacker News Reader

Lack of CSPRNG Threatens WordPress Sites

threatpost.com

36 pointsdavio16 comments

This is a very slanted piece. Read the original Trac ticket [1] instead. Arciszewski's original patch wasn't merged because it was overly broad, lacked unit tests, and had whitespace problems. He also started emailing one of the lead developers directly [2] instead of the security team, then got up in arms about lack of response.

[1] https://core.trac.wordpress.org/ticket/28633

[2] https://core.trac.wordpress.org/ticket/28633#comment:25

I would like to clarify that Andrew Nacin is not just "one of the lead developers", he was the security team member who self-assigned this deficiency.

Let me put it another way: I contacted the security team, Nacin responded. Then a mix of human and technological error (he says it was an aggressive spam filter) led to a communication breakdown.

> Arciszewski's original patch wasn't merged because it was overly broad, lacked unit tests, and had whitespace problems.

The problem was that my subsequent updates that addressed these issues were met with radio silence. Now the developers have gotten actively involved and they're on version 9 (thanks to dd32). Since the FD post, their response has been largely professional, proactive, and conservative. I have no complaints there.

EDIT: Also, my follow-up post to FD about this: http://seclists.org/fulldisclosure/2015/Feb/53

MT rand is truly bad at generating security-sensitive randomness. The exploitability of mt_rand is situational, though, and depends on:

* How long a single process with a single bucket of mt_rand state runs and reveals its state (if it's reloaded over and over, you get fewer bites at the apple to recover that state)

* How it's seeded (if you're in a position that requires you to recover state across multiple reloads)

* How much state is actually revealed (classic example: mt_rand instances that extract a single byte at a time, out of its 32 or 64 bit output)

It's never, ever a good idea to use mt_rand for security, but its mere use is probably not necessarily a bona fide vulnerability.

Right. There was >= 1 mistake I made during the analysis and reporting phase, but all parties agree that adopting urandom is still a good idea.

It's frustrating because mt_rand is just complicated enough to require this analysis. You should look at it the same way you do an uninitialized pointer variable in C, or maybe an offset NULL pointer write: very bad, but not necessarily exploitable.

Of course.

I proposed a theoretical way to abuse a hypothetical RNG prediction (if any were possible). Whether or not it's exploitable is, frankly, far above my understanding or pay grade. Whether it's exploitable today, versus whether it will be exploitable 10 years from now are even harder to say. If any advancements are made that cause the existing wp_rand() to become more fragile, it will probably be people far more intelligent than I am that will think of it.

(Disclaimer: Considering I don't and probably never will get paid for any of the bugs/patches I submit to open source projects, that pay grade is effectively $0.)

I'm only interested in seeing it fixed rather than proving that it can be pwned. Getting a CVE and then posting to FD were just steps I took because it appeared that I was being ignored. I now know that it wasn't intentional.

According to this post it seems like you need 624 consecutive values from mt_rand to recover the seed: https://jazzy.id.au/2010/09/22/cracking_random_number_genera...

(I agreed with everything you said, but it was just hard to follow without understanding how mt rand is usually cracked)

It's more complicated than that. The poster here isn't "cracking" MT, he's recovering its internal state completely. Partial information gets you to a place where you can run a cracking-like process against a system of constraints, though.

In any case: as Stefan Esser points out on Twitter, Wordpress doesn't rely on mt_rand for its password tokens.

Unless I'm reading this wrong, wouldn't it require someone generating a new password, then never changing it to something else?

I think that's typical. Not sure if this is the case, but I think the danger would be if you are able to use a "forgot password" link to enable the token.

Indeed, create a new throw away account; find out where in the PRNG table the password came from for this throw away account. Use that information to guess the next "Reset password" password then use that to hijack the target account.

It says there is no exploit as yet, but I imagine one would revolve around a malicious user with an account on that instance (either because they should have or because they've gained one via another exploit) using the reset feature to repeatedly reset their own account. If they are able to gain kowledge of the RNG's internal state by using information gleaned from many runs of this process, they can then use the feature against another account and guess the reset token that gets generated, allowing them to gain control of the account without needing to receive the password reset email (which will still go to the right user at that stage).

How practical such an attack would be is debatable, but it is certainly possible and perhaps someone more skilled at being a malicious user than I am can thing of something "better".

I only had a quick look at the affected code but it seems an attack would take the following format.

1: Craft a request to trigger a password reset for the admin account.

2: Then predict the token that would be generated and use this to access the reset and change the password.

This would be feasible because the token is predictable if you know the mt seed which is the only random number used in the token generation.

Whilst this is not completely straightforward, anyone with access to the machine (including on the same shared host) could easily find out the seed, and of course there are plenty of other vectors for machines leaking this information.

Well, let's assume I can wave a magic wand and predict the next PRNG output.

These are the hypothetical next steps to abuse this capability:

    1. Create password resets for a non-admin user account whose inbox I can read.
    2. Predict the next token that will be issued.
    3. Request a password reset for the blog owner.
    4. Use predicted token to change the admin password.

The solution is to use a true CSPRNG with access to high-quality entropy (i.e. /dev/urandom) rather than relying on a userspace RNG based on mt_rand(), uniqid(), and fast cryptographic hash functions.

The lion's share of criticism I've received is that the userspace CSPRNG is good enough to stop this attack. I subscribe to the "use urandom" school of thought that even the most paranoid yet well-informed crypto experts subscribe to.

The rest of the criticism I've received was in the realm of "why bother, just SQLi one of the horribly written WordPress plugins they'll inevitably install?"

Is there a WordPress plugin that implements the updated RNG? The `wp_rand` function is pluggable.

It's heartening to see this addressed before it becomes a vulnerability.

Mm, seems a bit hyperbolic, like a Wired article.

Reply on news.ycombinator.com