Dealing with vulnerable plugins

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Dealing with vulnerable plugins

Daniel Beck
Hi everyone,

When the security team receives a report about a plugin, we try to contact the maintainer and work with them to fix the issue. But between unmaintained plugins, unresponsive maintainers, or maintainers with no time to fix even security vulnerabilities, this doesn't always work out.

Unfortunately, the security team does not have the capacity to fix all security vulnerabilities in all plugins -- so we may have reports, but no way to fix the reported problems. Just sitting on the reports and hoping for a new maintainer to dump the issues on is not a solution.

So what can we do instead?

My plan is that we adopt a policy similar to that of Wordpress[1] and Drupal[2] (and possibly Typo3[3]):

We try to contact the maintainer. If they refuse (no time, no interest), or don't respond in a timely manner (several weeks), and the security team doesn't have the capacity to fix it, do the following:

1. Publish a security advisory about the plugin, describing the nature of the vulnerability as usual, but noting that there is no fix other than no longer using the plugin (if there are workarounds, include them).
2. Stop publishing the vulnerable plugin on the Jenkins update site.
3. Add metadata to the plugin site indicating vulnerable plugins to inform admins who already have the plugin installed.

#1 and #2 can be implemented immediately, but #3 needs infra and core support. That said, it's more of a 'convenience' feature. The important bits really are #1 and #2.

I will implement this plan going forward unless there are well-reasoned objections.

Daniel

1: https://wordpress.org/about/security/
2: https://www.drupal.org/security-team
3: I found https://typo3.org/teams/security/security-bulletins/typo3-extensions/typo3-ext-sa-2016-020/ which indicates they use a similar approach.


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/98B8D5E5-019E-48F5-9AD3-0CDFD8EC55F5%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Dealing with vulnerable plugins

Ulli Hafner
> 1. Publish a security advisory about the plugin, describing the nature of the vulnerability as usual, but noting that there is no fix other than no longer using the plugin (if there are workarounds, include them).
> 2. Stop publishing the vulnerable plugin on the Jenkins update site.
> 3. Add metadata to the plugin site indicating vulnerable plugins to inform admins who already have the plugin installed.
>

I think 1 and 3 is ok, but 2 is a little bit to harsh (depends on the type or severity of vulnerability). I think if 1 and 3 is available an admin can decide on his own whether to install a plugin or not.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F19A59C9-3A7B-43AC-B116-498D0F88E80F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Dealing with vulnerable plugins

stephenconnolly
I think it would be irresponsible of the project to continue to publish a plugin with a known vulnerability. If and admin really wants to install it they can pull it down via the maven repository

On 2 November 2016 at 14:24, Ullrich Hafner <[hidden email]> wrote:
> 1. Publish a security advisory about the plugin, describing the nature of the vulnerability as usual, but noting that there is no fix other than no longer using the plugin (if there are workarounds, include them).
> 2. Stop publishing the vulnerable plugin on the Jenkins update site.
> 3. Add metadata to the plugin site indicating vulnerable plugins to inform admins who already have the plugin installed.
>

I think 1 and 3 is ok, but 2 is a little bit to harsh (depends on the type or severity of vulnerability). I think if 1 and 3 is available an admin can decide on his own whether to install a plugin or not.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F19A59C9-3A7B-43AC-B116-498D0F88E80F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx_85jv9wOZ_Tw5SP74jDscKcL1HHH4fNP%3DiupkpuASMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Dealing with vulnerable plugins

jieryn
Plus, #2 only stops new installs.... All three items seem good practice.

On Wed, Nov 2, 2016 at 10:35 AM, Stephen Connolly
<[hidden email]> wrote:

> I think it would be irresponsible of the project to continue to publish a
> plugin with a known vulnerability. If and admin really wants to install it
> they can pull it down via the maven repository
>
> On 2 November 2016 at 14:24, Ullrich Hafner <[hidden email]>
> wrote:
>>
>> > 1. Publish a security advisory about the plugin, describing the nature
>> > of the vulnerability as usual, but noting that there is no fix other than no
>> > longer using the plugin (if there are workarounds, include them).
>> > 2. Stop publishing the vulnerable plugin on the Jenkins update site.
>> > 3. Add metadata to the plugin site indicating vulnerable plugins to
>> > inform admins who already have the plugin installed.
>> >
>>
>> I think 1 and 3 is ok, but 2 is a little bit to harsh (depends on the type
>> or severity of vulnerability). I think if 1 and 3 is available an admin can
>> decide on his own whether to install a plugin or not.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/F19A59C9-3A7B-43AC-B116-498D0F88E80F%40gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx_85jv9wOZ_Tw5SP74jDscKcL1HHH4fNP%3DiupkpuASMA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAArU9iYzJbFRudmn82%2B4%3DxPHdtMfkNfnPR8bm7iP%2Be0FKavEzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Dealing with vulnerable plugins

Baptiste MATHUS

+1 for that plan.
Given a real security issue, the Jenkins Project is IMO definitely expected to take down the offending plugin to stop propagation as much as possible. This is not a final measure, it can always be made public again once a fixed release has been published.


Le 2 nov. 2016 4:33 PM, "jieryn" <[hidden email]> a écrit :
Plus, #2 only stops new installs.... All three items seem good practice.

On Wed, Nov 2, 2016 at 10:35 AM, Stephen Connolly
<[hidden email]> wrote:
> I think it would be irresponsible of the project to continue to publish a
> plugin with a known vulnerability. If and admin really wants to install it
> they can pull it down via the maven repository
>
> On 2 November 2016 at 14:24, Ullrich Hafner <[hidden email]>
> wrote:
>>
>> > 1. Publish a security advisory about the plugin, describing the nature
>> > of the vulnerability as usual, but noting that there is no fix other than no
>> > longer using the plugin (if there are workarounds, include them).
>> > 2. Stop publishing the vulnerable plugin on the Jenkins update site.
>> > 3. Add metadata to the plugin site indicating vulnerable plugins to
>> > inform admins who already have the plugin installed.
>> >
>>
>> I think 1 and 3 is ok, but 2 is a little bit to harsh (depends on the type
>> or severity of vulnerability). I think if 1 and 3 is available an admin can
>> decide on his own whether to install a plugin or not.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/F19A59C9-3A7B-43AC-B116-498D0F88E80F%40gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx_85jv9wOZ_Tw5SP74jDscKcL1HHH4fNP%3DiupkpuASMA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAArU9iYzJbFRudmn82%2B4%3DxPHdtMfkNfnPR8bm7iP%2Be0FKavEzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS46R8HN4msnUGcBmPSt4qxQtL7Q4o7AgO-xA3V61NiSNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Dealing with vulnerable plugins

Michael Neale-2
In reply to this post by Daniel Beck
I like the sound of it, and seems a well trodden path as used by those other projects mentioned.

On Wednesday, November 2, 2016 at 11:59:28 PM UTC+11, Daniel Beck wrote:
Hi everyone,

When the security team receives a report about a plugin, we try to contact the maintainer and work with them to fix the issue. But between unmaintained plugins, unresponsive maintainers, or maintainers with no time to fix even security vulnerabilities, this doesn't always work out.

Unfortunately, the security team does not have the capacity to fix all security vulnerabilities in all plugins -- so we may have reports, but no way to fix the reported problems. Just sitting on the reports and hoping for a new maintainer to dump the issues on is not a solution.

So what can we do instead?

My plan is that we adopt a policy similar to that of Wordpress[1] and Drupal[2] (and possibly Typo3[3]):

We try to contact the maintainer. If they refuse (no time, no interest), or don't respond in a timely manner (several weeks), and the security team doesn't have the capacity to fix it, do the following:

1. Publish a security advisory about the plugin, describing the nature of the vulnerability as usual, but noting that there is no fix other than no longer using the plugin (if there are workarounds, include them).
2. Stop publishing the vulnerable plugin on the Jenkins update site.
3. Add metadata to the plugin site indicating vulnerable plugins to inform admins who already have the plugin installed.

#1 and #2 can be implemented immediately, but #3 needs infra and core support. That said, it's more of a 'convenience' feature. The important bits really are #1 and #2.

I will implement this plan going forward unless there are well-reasoned objections.

Daniel

1: <a href="https://wordpress.org/about/security/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwordpress.org%2Fabout%2Fsecurity%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG_d7b_33iU6Gx6cPf1j94t14D6nQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwordpress.org%2Fabout%2Fsecurity%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG_d7b_33iU6Gx6cPf1j94t14D6nQ&#39;;return true;">https://wordpress.org/about/security/
2: <a href="https://www.drupal.org/security-team" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.drupal.org%2Fsecurity-team\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHWQUy1aN7bNYT-9omJQadDeN7cyQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.drupal.org%2Fsecurity-team\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHWQUy1aN7bNYT-9omJQadDeN7cyQ&#39;;return true;">https://www.drupal.org/security-team
3: I found <a href="https://typo3.org/teams/security/security-bulletins/typo3-extensions/typo3-ext-sa-2016-020/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Ftypo3.org%2Fteams%2Fsecurity%2Fsecurity-bulletins%2Ftypo3-extensions%2Ftypo3-ext-sa-2016-020%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF5Hht-PuAiFAHmkrdomw9HsLt3nw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Ftypo3.org%2Fteams%2Fsecurity%2Fsecurity-bulletins%2Ftypo3-extensions%2Ftypo3-ext-sa-2016-020%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF5Hht-PuAiFAHmkrdomw9HsLt3nw&#39;;return true;">https://typo3.org/teams/security/security-bulletins/typo3-extensions/typo3-ext-sa-2016-020/ which indicates they use a similar approach.


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/505be1f3-39a8-4ab6-9b2d-452450f0ef60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Dealing with vulnerable plugins

Daniel Beck
In reply to this post by Daniel Beck

> On 02.11.2016, at 13:59, Daniel Beck <[hidden email]> wrote:
>
> 3. Add metadata to the plugin site indicating vulnerable plugins to inform admins who already have the plugin installed.

FTR this feature made it into 2.40 and Oliver accepted it into 2.32.2. Some screenshots in the core PR.

https://github.com/jenkinsci/jenkins/pull/2680 
https://github.com/jenkinsci/backend-update-center2/pull/96 
https://github.com/jenkins-infra/backend-jenkins-plugin-info-plugin/pull/11 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/40B9ACDA-F95C-41F6-AA06-379C2AC48A6D%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Dealing with vulnerable plugins

Daniel Beck
In reply to this post by Daniel Beck

> On 02.11.2016, at 13:59, Daniel Beck <[hidden email]> wrote:
>
> 2. Stop publishing the vulnerable plugin on the Jenkins update site.

FTR this has now been implemented for the first time[1].

The circumstances that led here were a bit different than were discussed before though: The maintainer of the plugin, Chris Price, was actually quite responsive, but the discussion with him resulted in the decision that the plugin should just be removed.

1: https://jenkins.io/security/advisory/2017-03-20/#pipeline-classpath-step-plugin-allowed-script-security-sandbox-bypass

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F233EA0B-C3EC-4919-9F7B-A148123C649B%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.