WordPress.com Security Vulnerability Stirs Debate Over Responsible Disclosure

Late last week, Yan Zhu, a Staff Technologist for the Electronic Frontier Foundation publicly disclosed a security vulnerability she discovered with WordPress.com and how it handles cookies. More specifically, she discovered the “wordpress_logged_in” cookie being sent in the clear to a WordPress authentication endpoint. She was able to use the authenticated cookie to publish blog posts, view private posts, post comments on others blogs, see their stats, and related administrative tasks that didn’t require logging in a second time.

Cookies Security Featured Image
photo credit: Pedro Vezinicc

Zhu contacted security@automattic.com and security@wordpress.org as the directions say to within the WordPress core handbook. Within 24 hours of notifying Automattic, Zhu publicly disclosed the vulnerability on her blog. The information was picked up by Ars Technica resulting in millions of readers finding out about the security issue before a fix was available. What was once a good deed is now an example of irresponsible disclosure.

According to Wikipedia, responsible disclosure is defined as:

A computer security term describing a vulnerability disclosure model. It is like full disclosure, with the addition that all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details. Developers of hardware and software often require time and resources to repair their mistakes.

When asked why she didn’t give Automattic more time, Zhu responded:

However, in this case, I believe that 24hrs was a fair amount of time. The main reason is that SSL support nowadays is widely accepted as the bare *minimum* security guarantee that a website should provide for users’ private information, and this is essentially a bug in WordPress’s SSL support. “Only send auth info over SSL” has been the most basic security recommendation to website operators for the last 15+ years.

Although Automattic states they’ll try to contact the reporter within 24 hours, I’d give them at least 72. The WordPress core handbook states that in all cases, you should not publish the details. The Automattic submission form states, “If you happen to find a security vulnerability in one of our services, we would appreciate letting us know before disclosing the issue publicly.” Perhaps the Automattic submission form should also request that reporters not publish the details.

When Disclosure Becomes Irresponsible

Any time a security vulnerability is disclosed before it’s fixed within a reasonable time frame, it’s irresponsible disclosure. Of course, what is a reasonable time frame is subjective but common sense dictates at least 3-5 days to hear a response back. Besides, they have to verify and duplicate the report in order to come up with a fix. Even if the issue is already known to attackers or is easy to find, it doesn’t make it ok to publicize it through the media. These types of actions fan the flames and make the reporter look like the bad person.

When it comes to how long of a time frame is acceptable before going to the public, everyone likely has a different answer. It also depends on what has gone on behind the scenes. For instance, when was it reported and when did the company respond back? Did they promise a fix but haven’t released it in months? In rare instances, publicizing a vulnerability is the only way to get a company to act but should be treated as the nuclear option.

In the comments of Zhu’s article, Matt Mullenweg thanked her for the report with a request that she allow more time for Automattic to act.

Thank you very much for finding and investigating this problem. If there’s a next time, I would definitely appreciate it if you gave us a few days more next time to protect users before it’s public.

Do you think Zhu is in the wrong for publishing details of the security issue too soon or was 24 hours enough time for Automattic to implement a fix? If you discovered a security vulnerability and reported it to the vendor, what would need to happen to convince you that publicizing is the only way to get it fixed?


44 responses to “WordPress.com Security Vulnerability Stirs Debate Over Responsible Disclosure”

  1. Thank you for the thoughts Jeff. In this case I’ll say that the public disclosure after only 24 hours was incredibly irresponsible. To assume that a major project can “flip a switch” in regards to a bug like this that quickly, assuming the ones who received it were even available that day, was naive at best or malicious at worst.

    See, this isn’t the first time I’ve seen disclosures like this and I am both pursuing and have been pursued by them in the past. In my own work I’ve never once had someone tell me a disclosure privately. Every single time someone finds something they immediately post it to the world seemingly in search of some sort of glory. On the flip side I’ve been bouncing such disclosures back and forth with 2 products for months. In one case they simply don’t care and in the other the bug is so integrated into the product that fixing it takes time (yet I know they are working on it). In both cases what would public disclosure bring other than putting it on a resume one day? Even in the case of the non-responsive company rather than disclosing it to the public I have instead made their distribution channel aware of the issue in hopes that pressure can be applied with respect and without undo burden on the community.

    To get off my rant these items should never be disclosed to the public in such a fashion until after the fix is available. To do otherwise serves no purpose other than that of the the person who found it.

    • I totally agree with you. I still wonder what advantage can bring to the community such an early disclosure. As a website owner and developer I’m upset because Yan Zhu put my client’s websites at risk before a patch was even available, so I couldn’t do anything to protect them.

      And 24 hours is unreasonable for many reasons. First, he didn’t know how complex it can be fixing the bug, so maybe he could wait hearing back from Automattic. But even if the bug could be fixed in one day, you must allow time for anyone to update their websites, and this cannot happen overnight even with automatic updates.

      • She didn’t do a very good job of making this clear, and the various media reports haven’t either, but the vulnerability is not in WordPress Core; it’s specific to WordPress.com.

        There is a related issue in Core (#20276), but that’s been publicly known for over 2 years.

        • Nacin responded to this comment elsewhere, but 2 years is incorrect. He said (in reference to your comment on this blog):

          1) The EFF staffer was not representing the EFF.

          2) The issues reported publicly last week have essentially nothing to do with the blog post linked here.

          3) The issues reported publicly last week have to do with custom WordPress.com functionality and configuration, and not WordPress core.

          4) The full disclosure was well-intentioned. Unfortunately, nuance is a major role when discussing responsible disclosure. I have seen countless “full disclosure” reports that are wrong and invalid, or worse, that the reporter thought was “minor” but in reality is far more complex and deserved greater time. Part of that complexity here is that the issue was with WordPress.com the service, not WordPress the software.

          5) I have seen many responsibly disclosed reports that are invalid. Responsible disclosure prevents these from escaping into the public. I’d question any shift to full disclosure by Ry Satterfield specifically because of this.

          6) Full disclosure versus responsible disclosure for *software* is a whole different ballgame than what occurred here. It is a lot harder to justify full disclosure when we’re not dealing with a software vendor but with a hosted service.

  2. I’d say 24 hours is too soon to publicize it, especially if it affects the .ORG version as well. Rolling out a change to WordPress.com users could be possible, but if this vulnerability affects “joe public” sites, it will obviously take a bit longer to get and the chances of the disclosure doing harm increases.

  3. 24 Hours on such a huge vulnerability is plenty of time to at least get a reply with a request to withhold disclosure.

    Rather than trying to demonize the person who found the gaping security hole, maybe we should talk about how responsible it was to use the security practices that allowed this bug out into the wild.

    • It’s not an either/or proposition, though, is it? Even if Automattic were irresponsible in the way they allowed this to occur, this doesn’t legitimize Ms. Zhu’s behavior. She was just looking for fame — but she’s probably only discovered notoriety.

  4. I think the issues here are more nuanced than the article depicts, and a more complete picture should have been painted.

    There’s actually a large camp of security researchers who advocate for what’s known as “full disclosure” instead of “responsible disclosure” in certain situations, and Yan was following the principles of the former philosophy when she announced the vulnerability.

    She explains this in detail at https://zyan.scripts.mit.edu/blog/wordpress-fail/#comment-70 and in subsequent comments, and she also references articles that support her position from several respected security professionals.

    We can have a valid debate about the merits of each philosophy, but I think that framing Yan’s actions as careless rather than informed and principled is a serious failure of the article.

    Similarly, I think that any commenters who are criticizing her motives when this article is their only frame of reference are acting out of ignorance. She isn’t some unknown script kiddie trying to get 15 minutes of fame on Packet Storm; she’s an accomplished security researcher who happened to notice the vulnerability while working on one of her own projects, and then responded to it in a manner consistent with accepted disclosure practices.

    • Actually, she doesn’t. In fact, she does quite the opposite, and virtually admits to being careless:

      “Disclosure timeline:

      Wed, 21 May 2014 16:12:17 PST: Reported issue to security@automattic.com, per the instructions at http://make.wordpress.org/core/handbook/reporting-security-vulnerabilities/#where-do-i-report-security-issues; at this point, the report was mostly out of courtesy, since I figured it had to be obvious to them and many WP users already that the login cookie wasn’t secured (it’s just a simple config setting in WordPress to turn on the secure cookie flag, as I understand it). Received no indication that the email was received.

      22 May 2014 16:43: Mentioned the lack of cookie securing publicly. https://twitter.com/bcrypt/status/469624500850802688

      In other words, she wasn’t following any philosophy at all, just making a careless assumption without much thought. She’s condemned herself by her own words.

      • I don’t think your interpretation of her words is correct; they are consistent with the philosophy of full disclosure.

        Her assumption that the vulnerability was known to Automattic was not a careless one, it was a very safe one to make, and one that anyone in her position would have made. It *is* a very obvious vulnerability. If you don’t want to take my word for it, I’d challenge you to find any well-respected WordPress developer who claims otherwise.

        Plenty of good people disagree about whether her choice of full disclosure vs responsible disclosure was the correct one, but I haven’t seen anybody disputing that it was an obvious vulnerability.

        So, we have situation where a vulnerability is known to the company and to attackers, has existed for years without being fixed, and has the potential to critically impact users. That is a classic case for full disclosure.

        Again, you’re free to disagree with her decision. If you feel like she should have given Automattic more time to respond, I think that’s a completely valid position, and one that I’m actually sympathetic to. But I think that questioning her motives is completely unfounded and in poor taste.

        • So you’re telling me that making assumptions about security — and remember, we are talking about WordPress users’ security here, not Automattic’s — is perfectly sound practice?!

          Would it be OK for a home alarm company to make similar assumptions?

          • Not necessarily. I’m not trying to convince you that full disclosure was the correct choice in this situation. Maybe it was, maybe it wasn’t; that’s not the point I’m trying to make.

            What I’m saying is that full disclosure is a commonly accepted practice among security researchers, and that Yan’s actions were consistent with full disclosure. I think those two facts are irrefutable.

            You don’t have to like that full disclosure is a commonly accepted practice, but you can’t deny that it is. You don’t have to agree that Yan’s actions were the correct ones, but you can’t claim that they weren’t consistent with full disclosure practices.

            My point is that responsible disclosure is not the only valid philosophy; full disclosure is also a valid philosophy. Each has pros and cons, and each applies better to some situations than others. Both positions are advocated for by respected, intelligent authorities in the field, and people on both sides are following their convictions about how best to protect users.

            You’re more than welcome to disagree with her choices, but it is intellectually dishonest to frame her as some careless teenager recklessly endangering users for shits and giggles when she is actually an intelligent, thoughtful advocate for user’s rights who honestly believes that she acted in the best interest of users.

            I don’t have a problem with anyone disagreeing with her conclusions, but don’t attack her character or treat responsible disclosure as a sacred cow.

    • but I haven’t seen anybody disputing that it was an obvious vulnerability.

      Why does it matter whether it was obvious or not? If it was so obvious, then why wasn’t it fixed in which case none of this would have ever happened?

      It doesn’t matter to me how small or obvious a security issue is, if it’s publicized without a fix in place for users to take advantage of, it makes the person publicizing it the villain. Besides, who gets to decide whether or not something is so obvious that full disclosure wouldn’t do any further damage?

      I read the comments on her blog, her post, some posts linking to her posts and my post was the opinion that how this went down should not be considered standard procedure with a request to others who may end up in the same position to give the vendor some time before raising hell about it. It’s great that she reported it to the vendor instead of taking full advantage of it but at the same time, this situation presents a few opportunities to learn what NOT to do.

      I mean, if she waited 48-72 hours, who knows if this post would have ever been written.

      • @ Ian Dunn I didn’t say anything about “shits and giggles”. Nor am I treating anything as a sacred cow. Those are your words. I am talking about this one incident, nothing more or less.

        Don’t talk about intellectual dishonesty and then impute to me something I didn’t say, when I expressly said she did it for fame.

        I notice you didn’t suggest it would be OK for a home alarm company to make assumptions about security. No rational person would. I have no idea why the fact that this is online security makes any difference. It’s that irrationality that makes her motives questionable.

        • @KTS915, I apologize for misrepresenting your words. When you said that, “she was just looking for fame” and was “just making a careless assumption without much thought”, I felt like you were implying that she acted flippantly and carelessly rather than intentionally and thoughtfully, which is why I described it as “shits and giggles”.

          But you’re right, your specific accusation was that she was motivated by fame, so I should have been more accurate.

          I didn’t respond to your point about assumptions directly because I felt like it was trying to debate the merits of full disclosure, which is not what I’m interested in — except to the extent necessary to recognize that a rational, intelligent, sincere person could be an advocate of it. I’m perfectly happy if people want to criticize full disclosure, and I’m sympathetic to the reasons for doing so.

          My concern has always been about how Yan has been characterized, so I tried to refocus the thread on that topic.

          If don’t see how a rational person could advocate for full disclosure, I’d encourage you to read the two articles than Yan referenced. The first is by Bruce Schneier, who is one of the most well-respected experts in the computer security field, and the second is by Google’s security team, whose credentials don’t need any explanation.

          * https://www.schneier.com/essay-146.html
          * http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html

          I think there are completely valid reasons why you might disagree with those positions, but I don’t think it’s fair to claim that they’re irrational.

          • Thanks. I appreciate the apology.

            But, again, you misunderstand me. I’m not taking a philosophical position for or against full disclosure as a matter of principle. In fact, I can think of at least two situations when I’d support it (when an organization has shown, by its previous conduct, that giving it more time doesn’t work; and when an organization is trading on claims of security to make money when in fact its security is full of holes).

            I’m just criticizing Ms. Zhu in this particular circumstance. The good thing is that she (and probably others) might now give themselves (and not just those to whom they have reported a security issue) a bit longer to think about what they should do rather than just assuming that after 24 hours it’s OK to broadcast the issue far and wide.

      • A proponent of full disclosure would argue that it matters because it if it’s obvious to us, it’s also obvious to attackers, which means that they’re actively exploiting it. That’s a key component of the argument for full disclosure: a vulnerability exists if it exists; keeping it secret doesn’t change that. Keeping it secret isn’t even really keeping it secret, it’s just keeping it secret from users, because attackers *will* discover it on their own.

        In light of that, keeping it secret could actually help the attackers, because the users can’t do anything to protect themselves, and the company isn’t under any pressure to fix it, so it remains available for an extended period of time.

        Advocates of full disclosure argue that disclosing the vulnerability publicly is the best way to help users, because it forces the company to make fixing the hole a top priority.

        Again, I’m not trying to convince anyone that full disclosure was the correct approach in this situation, but I do think you have to recognize that it’s a valid argument made by well-respected experts in the industry, and that advocates of it are sincerely trying to protect users.

        You asked who gets to decide… I could turn that around and ask you the same question. Who gets to decide that something isn’t already known by attackers, or that users don’t have the right to know that they’re vulnerable? It’s a complicated issue and researchers have to make a tough judgement call.

        It’s awesome that you’re encouraging people to be more thoughtful and careful about how they disclose vulnerabilities, but I think the article criticized her position without accurately representing it. It didn’t mention her reasons for disclosing it the way she did, or the complicated nature of the debate, so it came across as just tearing down a straw-man, and I think that gives readers who aren’t already familiar with the other side of the debate a false impression.

        • I know that this is an infinite debate that will never end but while I agree that we have the right to know that there’s a vulnerability, you don’t have necessarily to give all the details of how to exploit it when you announce it.

          We’ve already seen many researchers announcing that they have found a vulnerability but then postponing all the details to when a fix will be published. In this way they put pressure on the developer, and don’t disclose too many details too early.

          Telling that there is a vulnerability is right, even explaining a workaround while waiting for a fix would be a good practice but disclosing any details means putting in the hand of any script kiddie the information to play, have fun, and make some damage.
          Try to at least to not make the situation any worse than it already is.

          • Yup, that’s a valid approach. Schneier points out some potential problems with it in his article, but none of the approaches are perfect. I think the discerning researcher just has to weigh the pros and cons for every specific situation and make the best decision they can. It’s a tough spot to be in.

    • So I’ve read http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html and https://www.schneier.com/essay-146.html and both articles have really opened my eyes. I find myself conflicted on which method of disclosure I support more. Schneier made some excellent points I never considered.

      It seems as though I’ve made an error in judgement regarding Yan Zhu’s actions but I can’t make heads or tails of which type of disclosure is a win win situation for everyone involved. There is even this proposal of partial disclosure worth considering http://planetzuda.com/2014/03/28/partial-disclosure-proposal-to-replace-proper-disclosure-in-infosec/

      • After reading through all this, it looks like this is the same vulnerability I discussed at a WordPress meetup in Oslo a couple of years ago. I was asked to provide information on WordPress security. One of the things I mentioned was the importance of securing your cookies. I explained that most big sites don’t even bother, and proceeded to demonstrate to the audience that WordPress.com didn’t protect themselves in this way either. I didn’t consider this to be announcing a vulnerability since it was blatantly obvious.

  5. There seems to be a lot of pointed disclosure here about a prolific security researcher, who works for, of all places, the Electronic Frontier Foundation. People should stop flaming her or questioning her motives. Matt chose to thank her and not flame her, why can’t the rest of us do the same?

  6. I think what she did is good.

    Why wasn’t this vulnerability found when they last updated? I am sure they check the code for dot com when they update things there. same for dot org, correct?

    I have said this many times here and other places…WordPress updates too quickly. Look at PHPBB for example, they don’t update just like that, like WordPress does.

    If EVERY line hasn’t been checked then don’t release that version of WP until EVERY line of the code has been checked.

    This was missed at some point.

    Quality over Quantity. I am willing to wait a few weeks more for the next release to have a SAFER release.

    Also,…that e-mail address…a reply to her should of been sent A LOT SOONER than 24 hours. Why wasn’t that e-mail monitored for those 24 hours?

    Automattic should be monitoring things a lot better.

    When there was an issue here at WPT, I tweeted Jeff. He looked into it. I think he replied within an hour or two. Voila.

  7. I’m confused. Isn’t this just saying that WordPress.com sends it’s cookies in the clear? I didn’t think that was news; I thought they’d been doing that for years. It did kinda baffle me as to why they did that, but I assumed they were aware of it and had some architectural reason for not fixing it.

    • I replied to your post this morning, but my comment looks like it’s in moderation and there seems to be some confusion over this point that keeps getting repeated, so I figured I’d reply here as well….

      The issue with WordPress Core that’s been known for 2 years (#20267) is a separate (albeit related) issue to the vulnerability that Yan disclosed concerning WordPress.com. Self-hosted WordPress.org sites are not vulnerable to the issue that Yan disclosed.

  8. WPTavern & Automattic… we get the relationship, and we hear the (not so) subtle defense – great.

    It has already been there for two years! Don’t try to turn the tables onto Zhu for reporting it.

    That’s like me saying, “Wow, I found a major problem with the ignition switch in my GM. I’ll wait to hear back from General Motors before I tell my mom, my neighbors, and my little girl thats off at college.”

    That doesn’t make any sense at all. Nor does it make sense for Zhu to keep quiet about it either.

  9. @ian – My reading of Bruce Schneier’s essay is that responsible disclosure with threat of full disclosure is actually the better approach. And Google recommends Schneier’s essay and then suggests a 60 day window.

    That would imply, at least to me, that full disclosure in only 24 hours is not actually consistent with those who generally advocate for full disclosure.

    IMO she could have waited at least 72 hours before posting. JMTCW.

    • You’re absolutely right that Schneier and Google were both advocating that researchers start with responsible disclosure, and then resort to full disclosure if the vendor doesn’t fix the vulnerability within a reasonable timeframe, but it’s important to recognize that they were saying that in the context of a general policy, while Yan was responding to a specific vulnerability whose nature arguably lends itself towards rapid full disclosure.

      The point in referencing those article was to show that responsible disclosure is often insufficient, and that full disclosure is an acceptable response if the situation warrants it (e.g., because the vendor isn’t acting quickly or, in this case, because it’s clear that the vulnerability is already known to attackers).

      From her comments, it sounds to me like Yan would mostly agree with Schneier and Google that private disclosure is generally the best way to initially respond to a discovery, and that is how she did initially respond, so I think the central issue is the length of time she waited.

      I’m guessing that if this had been a more esoteric vulnerability, one that was less likely to be actively known to attackers, that she would have waited much longer, but in this case I can see a compelling argument that waiting would have done more harm than good.

      Given that attackers are already exploiting it, what were the pros and cons of waiting before public disclosure? The downsides are that unskilled attackers were informed about the vulnerability, and there was bad PR for Automattic. The benefits were that it immediately gave users effective ways to mitigate the risk on their own, and that it put external pressure on Automattic to fix the vulnerability immediately.

      I’m not saying that I would have acted the same way if I had been in her shoes, but I can see why she weighed the pros and cons the way she did.

      • > so I think the central issue is the length of time she waited.

        Exactly. What I was saying, and I think probably everyone else who has issue with this is probably saying that 24 hours especially without confirmed receipt is not a reasonable time to wait before full disclosure. Given time zones, staffing levels, weekends, staff’s personal lives and so many other things it’s hard to imagine any reasonable way to justify her disclosure in only 24 hours unless a response was need to avoid loss of life or a terrorist attack.

        Since I have no idea her motives I won’t conjecture but I did read her responses to criticism and they all read like rationalization to avoid admitting she made an error in judgement. And thus far all that I’ve read in support of her actions has sidestepped acknowledging there was no excuse full disclosure in only 24 hours *and* before she even received an acknowledgement.

        Had she waited a reasonable time for an acknowledgement and then given reasonable time for response (72 hours in both cases is reasonable to me) I think few if any would have criticized her. So while she may be following an accepted response in “full disclosure”, her waiting only 24 hours effectively invalidates her claim to any moral high ground.

        • Personally, I never felt like her responses were empty justifications, but that’s admittedly pretty subjective, so there’s probably no point in quibbling over it.

          I think I came at the lack of acknowledgement from a different perspective, although I’m definitely sympathetic to your point of view. I was thinking that, from her perspective, the lack of any kind of response after 24 hours — crossing all times zones, in the middle of the week, after the security contact form said that we’d respond within 24 hours — could easily be mistakenly interpreted as a lack of interest, especially given the nature of the vulnerability (which one could reasonably assume was an intentional design decision, rather than an unfortunate combination of events, especially if one has been burned by companies in the past when trying to report similar issues).

          But yeah, like I’ve hinted at before, I personally would have waited much longer than 24 hours, but I’ve been trying to put myself in her shoes, and when I do that I’m able to see a compelling case for why she made the decisions that she did.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: