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