44 Comments


  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.

    Reply

    1. 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.

      Reply

      1. 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.

        Reply

        1. 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.

          Reply

          1. Hi Chris, I’m confused by your comment. Who are you replying to? Your comment was a direct reply to mine (indicated by the indentation), but the points that you copy/pasted from Nacin don’t seem to be referring to my comments at all.

            Trac says that #20276 was opened on 3/21/2012, which is what I was basing the 2 years remark on, but I’m happy to defer to Nacin if he says that that’s wrong.

            I never claimed Yan was acting on behalf of the EFF when she disclosed the vulnerability, or that it was a Core vulnerability rather than a WordPress.com one. In fact, I said the opposite in the very comment that you replied to.

            What is the URL for Nacin’s original comment? Having that context would probably clear up the confusion.


          2. I don’t think that’s the post Chris was referring to. It contains some similar quotes, but not the ones that he pasted above. There’s no mention of the age of the ticket, or Yan representing the EFF, etc.


  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.

    Reply

  3. I would wait and communicate privately with the vendor before letting it be known publicly.

    Reply
  4. PH

    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.

    Reply
    1. KTS915

      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.

      Reply

  5. 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.

    Reply
    1. KTS915

      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.

      Reply

      1. 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.

        Reply
        1. KTS915

          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?

          Reply

          1. 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.


    2. 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.

      Reply
      1. KTS915

        @ 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.

        Reply

        1. @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.

          Reply
          1. KTS915

            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.


      2. 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.

        Reply

        1. 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.

          Reply

          1. 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.


    3. 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/

      Reply

      1. 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.

        Reply
  6. Chris

    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?

    Reply

  7. 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.

    Reply

  8. 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.

    Reply

    1. 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.

      Reply

      1. Ian, thank you for your reply. For some odd reason your comment isn’t pending or posted. I will update the article.

        Reply
  9. bradleygriffin1

    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.

    Reply

  10. @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.

    Reply

    1. 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.

      Reply

      1. > 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.

        Reply

        1. 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.

          Reply
        2. KTS915

          Mike Schinkel has pretty much nailed it.

          Reply

Leave a Reply