Password-reset flaw haunts WordPress admins

Summary: Researchers are sounding the alarm for a serious administrator password-reset vulnerability affecting the latest version of WordPress, the popular open-source blog publishing platform.The flaw, which can be exploited via the browser, gives an attacker a trivial way to compromise the admin account of any WordPress of WordPress MU (multiple user) installation.

Researchers are sounding the alarm for a serious administrator password-reset vulnerability affecting the latest version of WordPress, the popular open-source blog publishing platform.

The flaw, which can be exploited via the browser, gives an attacker a trivial way to compromise the admin account of any WordPress of WordPress MU (multiple user) installation.

Proof-of-concept code demonstrating the problem is publicly available. A patch is currently being prepared for release soon.

Swa Frantzen, an incident handler at the SANS Internet Storm Center has a detailed explanation of the problem.

UPDATE (August 12, 2009): WordPress has shipped a fix for this "very annoying" problem.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

17 comments
Log in or register to join the discussion
  • Open source and PHP at its worst

    I cannot fathom the design decisions that went into PHP. Maybe that's because there weren't any.

    That "language" (I use that term in the broadest sense here) is accident upon accident, quirk upon quirk, patch upon patch.

    PHP is a complete mess without a single guiding vision other than to allow cowboy coders to whip up insecure and unstable sites with no knowledge of programming. I could write a book about the stupid decisions in PHP.

    While WordPress is one of the absolutely most insecure webapps ever written (it has been <i>plagued</i> by faults such as this), you can somewhat forgive the WP developers for this one. PHP has a bad and misguided behavior allowing arrays to be injected into parameters. Combined with weak and dynamic typing you <i>really</i> need to know all the quirks of PHP to avoid mistakes such as this.

    honeymonster
    • So I see you haven't written a line of PHP yourself...

      Don't go by what you read....actually write some.

      I'll give you this. It did get a bad rap from being easily accessible and easy to learn. But its hard to master like any of the real hardcore languages...C/C++ etc. For those of us that KNOW how to write code its a great and flexible language. For those that don't know how I suggest you learn or go to one of those platforms that codes for you.
      storm14k
      • What about making it harder to learn?

        Hi, if it is so easy to learn, but hard to master, then maybe they should raise the bar for entry into using it. I code, but not in PHP, so I can't comment too much on its design but according to Wikipedia the National Vunerability Database reported 35% of computer software vulnerabilities were PHP related! It does say that most of them were due to not following best practices, which is inexcusable, but can more not be done to check or account for these mistakes? I also think that the coders for Wordpress might be upset that you indirectly accused them of not knowing how to code! Maybe you are right with that assertion ;-)
        planruse
        • It doesn't need to be harder to learn.

          People simply need to learn to develop and those that want to use these projects need to do some research before just downloading and installing.

          As for the WordPress developers I'm accusing them of nothing. They made a mistake like developers on every project using every language/platform have made since the beginning of software. Blaming the language is not the answer.
          storm14k
          • I understand..

            that it was just a mistake but it seems that people who use PHP make a large number of them - surely some of the blame must lie with it?
            planruse
          • The problem is more about accesibility than anything.

            Anyone can set up a LAMP server and start developing with PHP. And in the beginning thats what happened. So right off the bat it got a terrible wrap. Its not really that other languages are safer but that many of them could not be accessed without spending some money to get started.
            storm14k
          • The problem is definitely with the language, PHP

            It consistently makes it easier to make risky, error prone code than to make robust, secure code.

            Case in point: Variable interpolation. On the surface it is an immensely useful feature. Pity it is so dangerous to use in a public faced application. For a long time PHP MySql libraries didn't even <i>support</i> parameterized queries. So string concatenation and (especially) variable interpolation were the preferred ways to synthesize SQL queries. Any sane developer will tell you what that can lead to. Today parameterized queries <i>are</i> supported, but they are still much harder to write than simple variable interpolation. So PHP programmers *still* churn out script after script with SQL injection vulnerabilities.

            The <i>really</i> smart PHP developers even used variable interpolation in require/include. That way you can easily get started with a homebrewed CMS: You just pass the "page" name as a querystring parameter and use variable interpolation to include the "meat" of the page. Pretty neat. Unfortunately (at least until recently) PHP allowed you to include/require scripts from remote locations over http. So now you not just have SQL injections, now an attacker can <i>include scripts of his own choosing</i> and execute on your box. Genius!

            honeymonster
          • And pray tell which language....

            ...DOESN'T allow you to write non parametrized queries? Didn't a rash of ASP.Net hacks occur just last year because of SQL injection? I knew one developer ASP.Net that had never even heard of SQL injection and had every app he had ever written vulnerable until the day he was introduced to it.

            Language makes no difference. You can churn out insecure stuff in any language. The difference with PHP was the availability of hosting and the ease in setting up your down dev environment that mirrored the production environment of the big boys. Anybody with the slightest inkling to program could do so and release their projects.
            storm14k
      • Oh my, I've written more PHP than you've eaten peas

        Thank you.

        It is a horrible language. This vulnerability is just one example of how the weak typing gets you time after time after time.
        Register globals, addslashes, magic quotes, unparameterized queries, include/require over http, variable interpolation.

        Puzzle, what is the value of this expression:

        5=="5ucks"

        Nah, the numeric literal 5 cannot possible be equal to a string. But YES, the above expression actually evaluates to true!
        honeymonster
        • What!!!

          Could you explain more as to why 5=="5ucks" PHP must be a nightmare to debug
          planruse
          • Explanation

            PHP is weakly typed (not just dynamic typed). When it reaches the numeric literal 5 and the "equality" operator it will try to "coerce" the operands into the same type.

            In the PHP developers wisdom this means that they'll try to convert the string "5ucks" into a numeric value.

            And how do they do that? Well, they parse the string, of course. Again, in their infinite wisdom they just <i>stop parsing</i> when they reach a non-numeric character. They don't throw an error or anything, because <i>that would make parsing harder</i>. So once the parser reaches the "u" character it stops. It already read the digit "5" so it converts that to a numeris.

            And ofcourse, 5==5, to the expression is true.

            PHP is full of such strangeness.

            Of course, somebody realized this to be a problem and sought a solution:

            <i>They invented yet another equality compare operator, the triple ===</i>. Genius. This operator only returns true if the two operands also are of the same type!
            honeymonster
          • Thanks

            I thought it must be ignoring the string part but wasn't sure on the reasoning behind it - or lack thereof!!
            planruse
          • Too much power for some people....

            ...is what it boils down to. I was taught by guys who learned on punch cards. There was no "compile and see" method to finding problems in your code. You had to know what you had before you punched the cards and spent you money on processing time on the machines. So they taught us with the same mentality.

            You weren't allowed to rely on the compiler to find your errors. You could do it for assignments but when tests came they were done by hand on paper. If you had an error as simple as leaving off a semicolon on the first line of C code then you failed because the rest of the application would not execute if compiled. You had to be able to step through logic yourself....not stepping through the debugger.

            So for me things such as what you have described are wonderful. It would have saved me a ton of time yesterday dealing with type differences in a Java based ETL solution. In fact today I'm about to move some of this stuff to Groovy to cut back on so much Integer.Parse() and the like. When you know how to use these features they are great. If you need something to tell you where you have errored then they are stumbling block. Simple as that.
            storm14k
        • You probably have...

          ...because I don't care for peas.

          Everything you listed is optional. If you use it in an insecure way that's your fault. If you need the language to help you code securely then use a framework like Zend or use another platform all together. But don't punish the people that know how to be meticulous with their code just because some people can't. If we did that there would be no computer industry because everything from C/C++ on down would be banned.

          And for your example you do know that if you wanted to check type as well that you use "===" right?
          storm14k
  • Here is how you can patch this manually

    http://www.formortals.com/temporary-fix-for-unauthorized-
    wordpress-password-reset/

    georgeou
  • Not really compromising the admin account

    I'm not sure what you mean by "compromise" but it does not look to me like this flaw will allow an attacker access to an admin account. It will only allow the admin password to be reset, which is done in such a way that the attacker will not see the new password.

    Along these same lines, note the errata posted here: http://seclists.org/fulldisclosure/2009/Aug/0115.html


    "An attacker could exploit this vulnerability to reset the admin account of any wordpress/wordpress-mu <= 2.8.3"
    twc_brian
  • RE: Password-reset flaw haunts WordPress admins

    Great!!! thanks for sharing this information to us!
    <a href="http://www.yuregininsesi.com">seslisohbet</a> <a href="http://www.yuregininsesi.com">seslichat</a>
    birumut