As a software vendor, there are many reasons to prefer responsible disclosure of security issues. But the most important reason is also less obvious: vulnerability reports need to be correct.

I’ve seen countless “full disclosure” reports that are wrong and invalid. Most of these could have been prevented by privately disclosing it to the vendor and allowing them the opportunity to respond.

Everyone sees WordPress in the headlines, over and over again, but no one ever notices the “this report is invalid” response. We’ve prevented countless invalid reports from being published simply because they were disclosed to us first. This is better for the software’s users, who are otherwise left to scramble every time they see a report. They are not an expert, and often, neither is the reporter.

There’s another angle here, though: sometimes, the vulnerability report is correct, but incomplete. This too can send everyone scrambling, starting with the vendor who was not given the opportunity to straighten things out.

When responsible disclosure works, it works really well. I offer Jetpack’s recent vulnerability as a recent case study. While this was discovered internally at Automattic, the effect is the same: they were able to quickly and thoroughly investigate the issues and follow through with a plan of action. During their investigation they learned the problem was far more severe than they originally identified, and that their initial proposed fix was incomplete.

There will always be individuals who want everything to be fully disclosed, and there are some great arguments for that. I’m not trying to sway you one way or the other. But if you’re trying to do the right thing — you’re doing full disclosure in the interest of users, possibly even providing a patch or steps to mitigate — working with the vendor is a good way to ensure you haven’t missed anything.

I’m not sure how many times now I’ve responded to a mailing list saying, “well, this isn’t a vulnerability,” or “your proposed patch is incomplete,” or “your patch makes it worse.” Or when I don’t respond to the mailing list because my thought is This is worse than the reporter realizes.

Security is nuanced.

Last week, a security researcher disclosed some issues with WordPress. They stated that WordPress issues a cookie in plain HTTP that identifies the user. Correct. They also stated that this cookie does not expire when the user logs out. Also correct.

She went on to state that the cookie has a lifetime of 3 years, that it can be used to mess with the account’s two-factor authentication settings, and change their email and other settings. She followed that up with “have notified them and waited 24hrs for response, none yet. guessing it’s a wontfix for now, since their SSL support is patchy.”

Yes, absolutely, SSL support in WordPress is patchy. (Coincidentally, fixing all of this was already slated for the next major release.) While you can force SSL for the dashboard, we don’t have the concept of forcing SSL for the front-end of the site. So, that “logged in” cookie is issued over plain HTTP. It’s trivial in a plugin to force that cookie to be secure, but of course most users aren’t going to do that. Of course, most users also aren’t using SSL (sadly).

WordPress also doesn’t have any concept of session management. The user is authenticated and a cookie is issued, but there’s no way for it to be automatically invalidated upon logout (without you changing your password). Changing this is a major architectural change we’ve been planning for some time. But this is also why cookies are designed with a limited expiration: just 48 hours, or 14 days if you click “Remember me.”

But the report was that it didn’t expire for three years, right? This is where it gets a bit weird. I’d love it if “Remember me” remembered you for 30, 90, or even 365 days, but WordPress will wait to make any changes until cookies can be invalidated. Some time ago, though, WordPress.com configured this cookie to last for three years.

Normally, this wouldn’t be that bad. You see, the “logged in” cookie is relatively harmless. It allows presentational things like the toolbar, edit links in your theme, and such. But you can’t use it to manage your account, change your email, or do anything particularly crazy. In fact, WordPress issues a separate, secure “auth” cookie used for the “wp-admin” dashboard. It’s like Amazon knowing who you are after six months of not being on the site, but asking you to log in when you start to check out.

On WordPress.com, however, a lot of settings can be managed outside of the dashboard, on their “new dashboard,” at wordpress.com/settings/. As you might have guessed by now, they were not requiring the “auth” cookie on this page, only the “logged in” cookie. That is the true critical vulnerability here. A number of decisions came together to make a latent issue a very real one. The issue wasn’t reported like this because the reporter isn’t familiar with the intricacies of user authentication internals in WordPress, nor should anyone expect them to. Rather, an assumption was made it was a design decision that would probably just be a “wontfix” due to “patchy” SSL support.

The disclosure was well-intentioned, but because it happened within just 24 hours, Automattic wasn’t able to react quickly enough to identify the actual issue and request that it not be disclosed until they got a fix in place.

I’m just trying to set the record straight on what happened, since I keep seeing confused tweets, blog posts, comments, and Facebook chatter. (Favorite Facebook comment, after I posted a brief explanation: “Did we just open all those nesting doll layers to discover the belly was empty?”) This situation probably could have been handled better by everyone involved, but that’s not really the point. The primary issue is now handled, and other issues are also being addressed. I don’t think this requires post-mortem blog posts with a side of FUD. I’m not looking for a debate on full disclosure versus responsible disclosure. And I certainly don’t think anyone should be questioning the researcher, who has spent years dedicating herself to making the Internet more secure.

In this case, WordPress.com the service was able to react quickly to mitigate this issue for all of its users. Of course, with software, holes can’t be closed so easily, and in this case, the situation was probably exacerbated by confusing WordPress.com the service with WordPress the software. That confusion is easy to understand, especially since some of these issues have roots in the core software.

Security is nuanced.

I’ve not linked to any previous posts because I don’t want this to be a criticism of any researcher or writer, but if you’re looking for background: 1 2 3. Also, related work for WordPress 4.0 is happening here.