Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
Description
The Slack plugin reveals the integration token in the global configuration. In environments when many people have access to view the global configuration, this presents a security vulnerability since the token appears to give access to quite a bit of the Slack instance (though it's not entirely clear where that's configured).
Attachments
Issue Links
- links to
Activity
Field | Original Value | New Value |
---|---|---|
Description | The Slack plugin reveals the integration token in the global configuration. In environments when many people have access to view the global configuration, this presents a security vulnerability since the token gives access to the | The Slack plugin reveals the integration token in the global configuration. In environments when many people have access to view the global configuration, this presents a security vulnerability since the token appears to give access to quite a bit of the Slack instance (though it's not entirely clear where that's configured). |
Workflow | JNJira [ 171807 ] | JNJira + In-Review [ 184485 ] |
Labels | security |
Priority | Minor [ 4 ] | Critical [ 2 ] |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |
Remote Link | This issue links to "CloudBees Internal OSS-1367 (Web Link)" [ 18727 ] |
SlackNotifier.DescriptorImpl.token, SlackNotifier.authToken, and SlackSendStep.token store what appears to be an authentication token in plaintext. This is a serious bug.
The short fix is to change SlackNotifier.DescriptorImpl.token to use Secret and f:password, delete SlackSendStep.token (without
JENKINS-27386there is no safe way to use it), and preferably delete SlackNotifier.authToken as well.The better fix is to update the plugin to use the credentials API and thus store only String credentialsId (cf. JENKINS-27398 for the case of SlackSendStep).