[wp-meta] [Making WordPress.org] #6939: Reporting Security vulnerabilities in plugins

[Making WordPress.org]

#6939: Reporting Security vulnerabilities in plugins
------------------------------+---------------------
 Reporter:  dd32              |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:  2nd-opinion       |
------------------------------+---------------------

Comment (by fearzzzz):

 Replying to [comment:3 dd32]:
 > I would like to think that a 'punishment' system shouldn't be required.
 If a reporter was to consistently make false reports then that would be
 within reason to have their account permanently banned or reporting
 permission limited.
 I'm sure that this is a «must-have» option, even if it's not needed in the
 very near future. Sooner or later, but someone will try to use this
 reporting functionality for, let's say, personal purposes. At this point,
 limited reporting permissions sounds really good. Like, you know, «your
 account isn't banned and we're not telling you to get out, but you're
 doing something wrong».


 > Per-field or as the entire submission?
 Good question. I think the proper title is a must over here, also it must
 be informative. I like how WPScan do it, i.e.: «WooCommerce Payments <
 5.6.2 - Unauthenticated Privilege Escalation», «WZone - Lite <= 3.1 -
 CSRF» and so on. A well-written title will give us all the basic
 information we need: name of the vulnerable component, range of vulnerable
 versions, minimum required user role to exploit the vulnerability, and the
 type of discovered vulnerability. IMO, this should be the «gold standard».


 > Is there any "standardised" .txt/.md format that some use?
 Many researchers are guided by the template that is required for Exploit-
 DB submits, but this only applies to the report header, and not everyone
 fills in the required fields with the correct data. So there is no single
 standard here. For example, I use my own template for reports.


 > what to do with the situation when the vendor doesn't understand what
 security/vulnerability is and what is required of him, and is anything
 required at all? Quite a common case.
 >> This is unfortunately something that the plugin security team has to
 deal with often.
 >> Quite often suggested fixes are ignored and insecure fixes are made,
 which requires further changes from the author.
 >> Educating plugin authors can only be done through better documentation
 of the problem, and examples of how to resolve it.
 Yeah, I understand.


 > In the case of WordPress.org plugins, if a author is not willing to fix
 something that the plugins team deems a security issue, then they can
 close the plugin. If the author wants their plugin, they need to work with
 everyone to ensure it's secure.
 Sounds legit.


 > Bad choice of words on my part. I meant in terms of researcher. This
 should be open to anyone, whether they're an employed security researcher,
 an individual researcher, or a vehicle mechanic who understand code.
 Awesome, thanks for the clarification!


 > Currently the plugins team take action in response to public disclosures
 mostly as the team was not made aware of the issue before hand (there are
 some deliberate 0day'ers) or due to being a volunteer team, did not get to
 the email in time (There have been cases where we're alerted a few days
 before the disclosure timeout happens, and some where the notification was
 misunderstood).
 Yeah, I know about this situation.


 > there are some deliberate 0day'ers
 Honestly speaking, sometimes I do this because there are simply no other
 options left. It's a rare case now, but still.


 > That's something you can help greatly with!  And why I'm open to
 discussion on this, rather than saying "This is what needs to be built and
 this is what everyone gets".
 Sounds good! I need to think about it.


 > I suggested in the ticket a profile entry for reporting security issues,
 but I intentionally didn't suggest a threshold to get a badge of some
 form, or a count of submitted reports, to partially remove the desire to
 submit many reports for extreme-low-effort issues for an 'awesome badge'.
 > Perhaps down the line we'd be able to look at a `Security Researcher`
 badge for those who submit enough valid reports against WordPress Core /
 Plugins / Themes / etc, with a percentage-accepted criteria, to encourage
 reporters to only submit things that are actually valid and tested.
 If it's a badge of distinction to be earned through honest and hard work,
 that would be great. I like it.


 > maybe it makes sense to implement some kind of rating that displays the
 average response time to an incident of the plugin author? It would be
 great to somehow reward the plugin author for a quick response to an
 incident with profile badge for example and highlight this information.
 >> Interesting idea! This is probably not something we could do for the
 first iteration, again, due to lack of data points. But rewarding plugin
 authors who do things right is definitely worthwhile.
 Awesome!


 > It would be great to somehow «force» plugin authors to write a honest
 changelog and not ignore/silence any discovered and confirmed security
 issues. Right now this isn't only disrespectful to security researchers
 and regular users/clients, but also creates confusion that could have been
 avoided.
 >> I do agree, and in a way that is partly the reason for this ticket. The
 plugins team are often not aware of plugins that have significantly severe
 vulnerabilities until public disclosure and it being talked about widely,
 simply as they're never made aware of it.
 >>
 >> Currently [https://developer.wordpress.org/plugins/wordpress-org
 /plugin-security/ the only documentation] we have on responding to a
 security report is not very direct on what they should do in this regard.
 Updating that page to strongly encourage changelog entries and crediting
 the reporter should be done. If you have any suggestions for wording
 changes to make to that page, come along to #pluginreview in Slack with
 them and we'll get it sorted.
 Count me in. I just need some time to think about this task.


 > Something that we could do here however, is forcibly prefix the `Upgrade
 Notice` for a security fix with information of that regard, or ensure the
 changelog mentions `Security` for such plugins.
 > This is one of those situations where we currently have limited ability
 to control the messaging from plugin authors, while we can encourage them
 to be transparent, we still have to rely upon them wanting to work with
 us.
 >
 > I think this is something we'd have to look at as a follow up, once we
 see how plugin authors actually respond to it. With some well documented
 steps they should follow (perhaps a checklist) many are likely to be more
 willing to.
 Yeah, I understand. From my personal experience, I would say that the
 first thing to do here is to «flip the script»:

 ''Someone found a vulnerability in your plugin? Yes. But this doesn't mean
 that you write «bad code» or you are a «bad person». This is a great
 opportunity to make your product more secured, better and join the
 community united by a common idea.''

 Many developers seem ashamed of their lack of knowledge, of their
 mistakes, and this has its consequences on many internal processes. But
 silence or ignoring security issues only makes the situation worse.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6939#comment:5>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org