Dealing with vulnerable plugins
110 views
Skip to first unread message
Daniel Beck
Nov 2, 2016, 8:59:28 AM11/2/16
to Jenkins Developers
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.
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.
Ullrich Hafner
Nov 2, 2016, 10:24:17 AM11/2/16
to Jenkins Developers
> 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.
> 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.
>
Stephen Connolly
Nov 2, 2016, 10:35:10 AM11/2/16
to jenkin...@googlegroups.com
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
--
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 jenkinsci-dev+unsubscribe@googlegroups.com.
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.
jieryn
Nov 2, 2016, 11:33:48 AM11/2/16
to jenkin...@googlegroups.com
Plus, #2 only stops new installs.... All three items seem good practice.
On Wed, Nov 2, 2016 at 10:35 AM, Stephen Connolly
<stephen.al...@gmail.com> 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 <ullrich...@gmail.com>
> 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 jenkinsci-de...@googlegroups.com.
On Wed, Nov 2, 2016 at 10:35 AM, Stephen Connolly
<stephen.al...@gmail.com> 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 <ullrich...@gmail.com>
> 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
>> 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.
>
>
>> 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 jenkinsci-de...@googlegroups.com.
> 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
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx_85jv9wOZ_Tw5SP74jDscKcL1HHH4fNP%3DiupkpuASMA%40mail.gmail.com.
Baptiste Mathus
Nov 2, 2016, 1:00:50 PM11/2/16
to Jenkins Developers
+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" <jie...@gmail.com> 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
<stephen.alan.connolly@gmail.com> 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 <ullrich...@gmail.com>
> 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 jenkinsci-dev+unsubscribe@googlegroups.com.
>> 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 jenkinsci-dev+unsubscribe@googlegroups.com.
> 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 jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAArU9iYzJbFRudmn82%2B4%3DxPHdtMfkNfnPR8bm7iP%2Be0FKavEzA%40mail.gmail.com.
Michael Neale
Nov 2, 2016, 6:54:05 PM11/2/16
to Jenkins Developers, m...@beckweb.net
I like the sound of it, and seems a well trodden path as used by those other projects mentioned.
Daniel Beck
Jan 11, 2017, 7:18:10 AM1/11/17
to jenkin...@googlegroups.com
> On 02.11.2016, at 13:59, Daniel Beck <m...@beckweb.net> wrote:
>
> 3. Add metadata to the plugin site indicating vulnerable plugins to inform admins who already have the plugin installed.
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
Daniel Beck
Mar 20, 2017, 6:50:39 PM3/20/17
to jenkin...@googlegroups.com
> 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
Reply all
Reply to author
Forward
0 new messages