[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       |
------------------------------+---------------------

Old description:

> Currently there are two main ways to report security issues to plugin
> authors:
> 1. Scour the plugin page for a Security reporting link and failing that,
> look for a company/personal contact, reach out via their contact form or
> email address, convince them to resolve the issue.
> 2. Email the plugins team with a report, have them forward the report on
> to the author(s) of the plugin, and let the plugins team choose to
> withdraw the plugin from the repository or not (Note: Most plugins are
> withdrawn upon a security notice, as currently there isn't a better way
> to manage whether things get fixed or not).
>
> Neither of these are ideal solutions, In the first, security vendors
> often find that their reports are missed, ignored, or simply not able to
> find a contact method for the author. That then causes them to use the
> second option.
> In the second, it requires time from a human reviewer to review the
> security report, determine if it appears legitimate, determine the plugin
> it relates to, check to see if the plugin has released a newer version,
> copy-paste the report to the plugin author, manage the communication with
> the author + explain the issue, likely close the plugin to keep track of
> the security issue, etc.
>
> Quite simply, neither is an optimal scenario, and with the number of
> plugins on the directory growing, and the number of security researchers
> who are invested in responsible disclosure growing, the human time
> required to manage this simply increases.
>
> There are likely a few ways we can resolve this, but, after discussing
> this with a few community members, plugins reviewers, and a few select
> security vendors, I'd like to propose one solution.
>
> **The proposal**
>  - Each plugin gets a `Report Security Issue` button, that links to..
>  - A form on WordPress.org, likely at a location such as `/plugins
> /report-security-issue/?plugin=example-plugin-slug-here`
>  - That form requests all the pertinent details, Plugin Version, Type of
> issue, Severity, Description, POC, Possible patch(es), Security Vendor
> details.
>  - That form creates an 'security incident' CPT entry, The details are
> emailed to the plugin author for action.
>
> From there, there are a few options, but I believe the above would
> suffice as an MVP, to streamline the process of getting security reports
> to the authors.
> Ideally however, We'd then...
>  - A security incident is created, and accessible via a private URL to
> the plugin committers, security vendor, and plugins team, at a url such
> as `/plugins/security-report/{UUID}/`
>  - Communication between the Security Vendor and Plugin Author can take
> place via comments on that page, instead of ad-hoc email. (Notifications
> of comments would still trigger an email)
>  - The Plugin authors details (email, etc) can remain private, likewise
> the security vendor could remain private. Perhaps it links with their
> 5ftf pledge and it's "This is a report from <username> from <Security
> Vendor>".
>  - Plugin Reviewers can see and comment if required.
>  - The incident can be marked as resolved in a given version (by any
> involved)
>
> Of course, as noted above, there are some issues around how to ensure
> things get fixed appropriately, but also that false reports or by-design
> doesn't impact the plugin.
>  - If the plugin author doesn't ACK the issue, the plugin is closed
> within a certain timeframe, this encourages authors to resolve the issue.
>  - If the plugin author does resolve the issue within a time limit, and
> the security vendor is satisfied, the plugin is never closed. This
> benefits the Plugin author and end-users.
>  - If the plugin author believes the reported issue is not valid, or the
> Security vendor believes the author is not making a reasonable attempt at
> resolving the issue, it can be escalated to the plugins team to make a
> decision.
>
> **Potential Issues / Caveats**
> 1. Not everyone understands what a Security vulnerability is.
>   - Requesting specific fields may increase the barrier to reporting,
> making it less likely to be problematic.
>   - Reports could still go via the plugins team for the initial report,
> only once a reviewer confirms it, would it (And future reports from the
> author?) then be forwarded on to the author. In other words; trusted
> reporters go straight through, not-yet-trusted gets moderated.
> 2. Security vendors have their own tools they may wish to use, asking
> them to use our system might be a challenge. Most should be at willing to
> use ours for submitting it though.
> 3. Plugin authors may already have a system in place, such as HackerOne
> or BugCrowd. Ideally we'd somehow integrate with those, but initially we
> could just disable ours if a security-reporting url is provided by the
> author.
> 4. Disclosure, Ideally issues would get disclosed at some point, for now
> this would be better left to the existing indexes of plugin
> vulnerabilities and we wouldn't be creating a disclosure index for now.
> At a later date it might be good to then use this data to say "Versions
> less than 1.2.3 are known insecure" and integrate that into core somehow.
>
> **Outcomes**
>
>  - This would also provide the plugins team a greater view into the
> security issues affecting plugins, trends of what they need to keep an
> eye out on in plugin reviews, what needs better documentation, etc.
>  - Would also allow the plugins security team to be aware "sooner" of
> high-severity issues that may warrant a security auto-update, or to be
> escalated to the team when that's going to be needed.
>  - Plugin authors can be assured that they'll get notified about security
> issues, no longer have their plugin closed for re-review unless no effort
> is made
>  - Security vendors no longer need to hunt around for a contact email
> address or contact form, unsure if the issue will get to the correct
> person.
>  - Security reporters would be able to get a trackable event on their
> profile, "Reported a security issue on a plugin."
>  - Plugin reviewers would no longer need to manually process every
> security report email
>  - Plugin reviewers might be able to offload some of the re-
> review/verification of the security fix onto the security reporter, as
> currently it's 'easier' for the reviewers to review it than go back to
> the initial reporter to get it checked
>  - Plugin Security Team time could be more targeted to supporting and
> reviewing issues as needed, and working on supporting plugin authors and
> security items rather than emails.

New description:

 Currently there are two main ways to report security issues to plugin
 authors:
 1. Scour the plugin page for a Security reporting link and failing that,
 look for a company/personal contact, reach out via their contact form or
 email address, convince them to resolve the issue.
 2. Email the plugins team with a report, have them forward the report on
 to the author(s) of the plugin, and let the plugins team choose to
 withdraw the plugin from the repository or not (Note: Most plugins are
 withdrawn upon a security notice, as currently there isn't a better way to
 manage whether things get fixed or not).

 Neither of these are ideal solutions, In the first, security reporters
 often find that their reports are missed, ignored, or simply not able to
 find a contact method for the author. That then causes them to use the
 second option.
 In the second, it requires time from a human reviewer to review the
 security report, determine if it appears legitimate, determine the plugin
 it relates to, check to see if the plugin has released a newer version,
 copy-paste the report to the plugin author, manage the communication with
 the author + explain the issue, likely close the plugin to keep track of
 the security issue, etc.

 Quite simply, neither is an optimal scenario, and with the number of
 plugins on the directory growing, and the number of security reporters who
 are invested in responsible disclosure growing, the human time required to
 manage this simply increases.

 There are likely a few ways we can resolve this, but, after discussing
 this with a few community members, plugins reviewers, and a few select
 security researchers, I'd like to propose one solution.

 **The proposal**
  - Each plugin gets a `Report Security Issue` button, that links to..
  - A form on WordPress.org, likely at a location such as `/plugins/report-
 security-issue/?plugin=example-plugin-slug-here`
  - That form requests all the pertinent details, Plugin Version, Type of
 issue, Severity, Description, POC, Possible patch(es), Security reporter
 details.
  - That form creates an 'security incident' CPT entry, The details are
 emailed to the plugin author for action.

 From there, there are a few options, but I believe the above would suffice
 as an MVP, to streamline the process of getting security reports to the
 authors.
 Ideally however, We'd then...
  - A security incident is created, and accessible via a private URL to the
 plugin committers, security reporter/researcher, and plugins team, at a
 url such as `/plugins/security-report/{UUID}/`
  - Communication between the Security reporter and Plugin Author can take
 place via comments on that page, instead of ad-hoc email. (Notifications
 of comments would still trigger an email)
  - The Plugin authors details (email, etc) can remain private, likewise
 the security reporter could remain private. Perhaps it links with their
 5ftf pledge and it's "This is a report from <username> of <CompanyName>"
 if part of a company, otherwise just "from <username>".
  - Plugin Reviewers can see and comment if required.
  - The incident can be marked as resolved in a given version (by any
 involved)

 Of course, as noted above, there are some issues around how to ensure
 things get fixed appropriately, but also that false reports or by-design
 doesn't impact the plugin.
  - If the plugin author doesn't ACK the issue, the plugin is closed within
 a certain timeframe, this encourages authors to resolve the issue.
  - If the plugin author does resolve the issue within a time limit, and
 the security reporter is satisfied, the plugin is never closed. This
 benefits the Plugin author and end-users.
  - If the plugin author believes the reported issue is not valid, or the
 Security reporter believes the author is not making a reasonable attempt
 at resolving the issue, it can be escalated to the plugins team to make a
 decision.

 **Potential Issues / Caveats**
 1. Not everyone understands what a Security vulnerability is.
   - Requesting specific fields may increase the barrier to reporting,
 making it less likely to be problematic.
   - Reports could still go via the plugins team for the initial report,
 only once a reviewer confirms it, would it (And future reports from the
 author?) then be forwarded on to the author. In other words; trusted
 reporters go straight through, not-yet-trusted gets moderated.
 2. Security reporters have their own tools they may wish to use, asking
 them to use our system might be a challenge. Most should be at willing to
 use ours for submitting it though.
 3. Plugin authors may already have a system in place, such as HackerOne or
 BugCrowd. Ideally we'd somehow integrate with those, but initially we
 could just disable ours if a security-reporting url is provided by the
 author.
 4. Disclosure, Ideally issues would get disclosed at some point, for now
 this would be better left to the existing indexes of plugin
 vulnerabilities and we wouldn't be creating a disclosure index for now. At
 a later date it might be good to then use this data to say "Versions less
 than 1.2.3 are known insecure" and integrate that into core somehow.

 **Outcomes**

  - This would also provide the plugins team a greater view into the
 security issues affecting plugins, trends of what they need to keep an eye
 out on in plugin reviews, what needs better documentation, etc.
  - Would also allow the plugins security team to be aware "sooner" of
 high-severity issues that may warrant a security auto-update, or to be
 escalated to the team when that's going to be needed.
  - Plugin authors can be assured that they'll get notified about security
 issues, no longer have their plugin closed for re-review unless no effort
 is made
  - Security reporters no longer need to hunt around for a contact email
 address or contact form, unsure if the issue will get to the correct
 person.
  - Security reporters would be able to get a trackable event on their
 profile, "Reported a security issue on a plugin."
  - Plugin reviewers would no longer need to manually process every
 security report email
  - Plugin reviewers might be able to offload some of the re-
 review/verification of the security fix onto the security reporter, as
 currently it's 'easier' for the reviewers to review it than go back to the
 initial reporter to get it checked
  - Plugin Security Team time could be more targeted to supporting and
 reviewing issues as needed, and working on supporting plugin authors and
 security items rather than emails.

--

Comment (by dd32):

 Replying to [comment:2 fearzzzz]:
 > - most likely, someone will try to abuse these forms and this isn't only
 spam [...] So basically the security researcher needs to be registered @
 wordpress.org to access the form, right? Does it make sense to introduce a
 «punishment» system for obvious fake reports?

 Yes, reporters would need to be registered.
 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.


 > - it would be nice not to make all the input fields of the form
 obligatory and give the ability to upload .txt or .md files. [...] Such
 forms are mostly convenient for companies, but not for researchers.

 Per-field or as the entire submission? Is there any "standardised"
 .txt/.md format that some use?

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

 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.
 (It's not uncommon for some plugins that are intentionally "insecure" to
 get security reports either - for example, an admin console that lets any
 user execute PHP, or a plugin that allows users to access any file on the
 server filesystem, a report against one of those would not warrant the
 plugin being closed, unless it was something like an authentication
 bypass)

 There's the scenario where the plugin security team can step in and fix
 the plugin too, although in that case, it would only be to make an update
 for end-users, the author would not retain access if they were not willing
 to support the plugin.

 > - does the term «security vendor» apply only to companies or to
 independent researchers as well?

 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.
 I'm going to go edit the ticket to read `security reporter` to be more
 inclusive.

 > - if the plugin author doesn't agree with the discovered vulnerability
 (which sometimes happens, and such a position is biased), then the
 researcher can simply «bypass» this communication routine by uploading a
 report to any vulnerability aggregator, which in the end will still force
 either the plugin author and/or the WordPress Plugins team to turn
 attention to this problem. At this point it makes sense to listen a little
 less to the opinion of the authors I believe. What do you think?

 I touched on this in the above answer, but this is a case where the
 security researcher would escalate it to the plugins team to intervene,
 and would result in the plugin being closed. That would ideally happen
 before the disclosure is made by a vulnerability aggregator.

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

 > - additional question: what should motivate independent researchers to
 use this form?

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

 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.
 Other platforms have a Leader Board system, that works for them, but I
 don't think it'd work for us.
 This is something that we'd probably only be able to identify the best
 solution for once we had enough reports / data collected.


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

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

 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.

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