When it comes to problems with the moderation of the WordPress Support Forum that led to us beginning to full disclose vulnerabilities until that inappropriate behavior is cleaned up there has been a continuing strange situation where people are mixing up cause and effect, somehow believing that we started our protest because we were banned from the Support Forum for our protest, which obviously makes no sense. The person that seems to at the heart of that mix up is the person in charge of the moderation of the Support Forum, Samuel “Otto” Wood, who also believes that “magic wizards” discover exploitable vulnerabilities in WordPress plugins.
In the comments of Ars Technica’s hit piece about us he commented and mixed things up again:
The forums are support forums. They’re not ways to contact plugin authors. They’re not ways to report security issues. No amount of wordplay will get around that fact. This person’s beef has been that his posts were removed, and this is true, because we do not allow those types of posts on the public forums. His response, honestly, makes no sense. He posts things publicly and creates fake accounts to do so, because we won’t let him post these things publicly in the forums. So, you break the rules because we told you that that is against the rules? Think you need a class on logic 101, mate.
It is hard to understand how he got so mixed and then is making it like we are mixed up, but from other things we have seen he doesn’t seem quite right, which is a problem when he isn’t just in charge the moderation, but one of the six members of the team running the Plugin Directory.
We also don’t know what fake accounts are, obviously a fake account on the website wouldn’t even work, since they are not real, but making sense seems to not be his strong suit. As part of our protest we only notify the developer of the disclosure through the Support Forum, which would stop if the inappropriate behavior of the moderators stopped.
In the comments that come after that you get more of his strange logic and why having him in the roles he is in is so problematic, seeing as he helps cause problems with the handling of the security of WordPress plugins and then blocks attempts to discuss that on the Support Forum, which might lead to them getting fixed.
Part way through the responses with him someone responded with this:
I’m not asking what you think “the best way to help users” is. I’m asking how (in the time before a fix is released) to inform end users they are currently running a vulnerable plugin. Or to state it another way, I’m asking how to implement this workflow:
* Vulnerability found.
* End users informed.
* Fix released.
Note that the “end users informed” comes before “fix released” and is working on the assumption that there is greater than zero time between the vulnerability being found and the fix being released.
Is my question still not clear?
The response from him is this:
Yeah, because why would users be informed before a fix exists? That makes no sense.
Separate from the full disclosures we are doing, vulnerabilities are frequently disclosed without a fix being available because someone else full disclosed a vulnerability, because the developer isn’t going to fix it for whatever reason, or because hackers are already exploiting it. So his solution is to leave people unaware that they are vulnerable until a fix is released, even though there may never be one.
The response to that was this:
Because they are vulnerable to the exploit, even if they don’t know about it. And if they are aware there is a vulnerability they can take steps to mitigate it while the wait for a fix.
And then from Mr. Wood:
If the “fix” is to remove the plugin and replace it, that that is also a valid fix. Presenting a problem without a solution to users doesn’t best serve them. Making an exploit public without a solution to it is irresponsible.
This doesn’t make any sense either, since the party able to solve this would be the developer of the plugin or the Plugin Directory team, who are not making exploits public. What makes that worse is that with vulnerabilities likely to be exploited we have repeatedly offered to provide the fixes for those if the developer isn’t doing that, so the Plugin Directory team would just need to check those and apply them. They seem to have no interest in that and with this guy’s logic, the reason for that probably doesn’t make sense.
The next response is this:
I’m not necessarily arguing for giving full details. I’m asking how to inform users they have been and still are vulnerable. What they do with that information is up to the user. Some may want to investigate their logs for anything suspicious. Some may want to immediately disable the plugin while a fix is being worked on.
If wordpress immediately removes plugins when a vulnerability report is released then great! There’s no reason not to tell users immediately. Otherwise there are mitigations that users can take if informed.
Why are you so resistant to users being able to make informed decisions? Not all wordpress admins are non-technical.
Then Mr. Wood writes this:
Why are you treating “users” like some kind of special class? The instant you release things to be public knowledge, then it is *public*. How do you propose to tell your magical set of “users” things without also telling literally everybody else in the world the same things?
Again, great logic there. Of course if something is already public then telling the users isn’t making it public, since it is already public. We have been trying to explain that to the team running the Plugin Directory for far too long.
Hackers Actually Find Vulnerabilities
A little further in that conversation Mr. Wood writes this
Yes, not releasing exploits to the public protects people because *that’s actually true*. This isn’t complicated. Hackers are not magic wizards. They mostly exploit publically released things because they are given the means to do so. Look at the history. It’s very simple and obvious.
We don’t know what to say about him believing that people discovering exploitable vulnerabilities are “magic wizards”, but in the real world in just the last couple of months, hackers have widely exploited vulnerabilities they look to have to discovered in the Freemius library used by many WordPress plugins and the plugin Easy WP SMTP. The former didn’t receive much news coverage, but we have seen a steady stream of probing for impacted plugins, some of which still haven’t been fixed and are still available in the Plugin Directory.
Just as a reminder that we unlike Mr. Wood, we are based in reality, two people responded to that with replies in line with what we have been trying to get through to the team running the Plugin Directory for over 7 years:
Security researchers aren’t “magic wizards” either. If they can find vulnerabilities why can’t black hats? Especially as the financial incentive can be much greater for zero day exploits.
Look I get that zero day exploits can be hard to detect, especially when they’re only used in targeted attacks (and not being sprayed everywhere by script kiddies). However this doesn’t mean they don’t happen. And we do know they happen.
It is a lie to declare to users that they’re safe while hiding the fact you know of vulnerabilities.
Otto, I’m confused as to why you think keeping a vulnerability secret helps the end user? I’m not talking about releasing PoC with the announcement, but as examples, WordFence and Sucuri both practice responsible disclosures where they’ve announced a disclosure without giving the specifics so end-users have the chance to make a decision about what to do. While disabling the plugin in the plugin repo definitely prevents additional users from installing insecure code into their system, keeping things quiet and not informing current users puts them at a disadvantage and at risk. Closing a plugin in the public repo is also a public announcement. The difference is Black hats watch the repo for when you close plugins so they can scan the source code for potential vulnerabilities to exploit. End users are left in the dark.
So far Mr. Wood hasn’t responded to those.