[JENKINS-50242] withCredentials step masking easily bypassed

Type: Bug
Resolution: Not A Defect
Priority: Major
Component/s: credentials-binding-plugin
Labels:
None
Environment:
Jenkins: 2.111
Plugin: 1.15

Similar Issues:
Powered by SuggestiMate

Show

A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret.

For this use case, withCredentials is broken:

node {
  stage('Break Security') {
    withCredentials([string(credentialsId: 'AWS_DEFAULT_REGION', variable: 'AWS_DEFAULT_REGION'),
    string(credentialsId: 'AWS_ACCESS_KEY_ID', variable: 'AWS_ACCESS_KEY_ID'),
    string(credentialsId: 'AWS_SECRET_ACCESS_KEY', variable: 'AWS_SECRET_ACCESS_KEY')]) {
      def exposedSecret = ""
      for(letter in env.AWS_SECRET_ACCESS_KEY) {
        exposedSecret = "$exposedSecret $letter"
      }
      echo "$exposedSecret"
    }
  }
}

The secret can be easily viewed.

Letting someone work on a pipeline is basically showing them the secrets that pipeline uses.
For this example I used "Secret Text", but it also happens with "AWS Credentials".

is duplicated by

JENKINS-60962 credential plugin security issue

Closed

relates to

JENKINS-54538 Ability to save unmasked credentials to file

Closed

JENKINS-61277 Document that Bitbucket Server admin token credential secures itself by forcing to SYSTEM scope

Open

links to

PR 49

mentioned in: Page Failed to load

Andres Pineros created issue - 2018-03-19 00:32

Andres Pineros made changes - 2018-03-19 00:33

Description

Original: A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret.

For this use case, withCredentials is broken:
{code:java}
node {
stage('Break Security') {
   withCredentials([string(credentialsId: 'AWS_DEFAULT_REGION', variable: 'AWS_DEFAULT_REGION'), string(credentialsId: 'AWS_ACCESS_KEY_ID', variable: 'AWS_ACCESS_KEY_ID'), string(credentialsId: 'AWS_SECRET_ACCESS_KEY', variable: 'AWS_SECRET_ACCESS_KEY')]) {
  def exposedSecret = ""
  for(letter in env.AWS_DEFAULT_REGION) {
  exposedSecret = "$exposedSecret $letter"
}
echo "$exposedSecret"
}
}
}{code}
The secret can be easily viewed.

Letting someone work on a pipeline is basically showing them the secrets that pipeline uses.

New: A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret.

For this use case, withCredentials is broken:
{code:java}
node {
stage('Break Security') {
withCredentials([string(credentialsId: 'AWS_DEFAULT_REGION', variable: 'AWS_DEFAULT_REGION'),
string(credentialsId: 'AWS_ACCESS_KEY_ID', variable: 'AWS_ACCESS_KEY_ID'),
string(credentialsId: 'AWS_SECRET_ACCESS_KEY', variable: 'AWS_SECRET_ACCESS_KEY')]) {
def exposedSecret = ""
for(letter in env.AWS_DEFAULT_REGION) {
exposedSecret = "$exposedSecret $letter"
}
echo "$exposedSecret"
}
}
}{code}
The secret can be easily viewed.

Letting someone work on a pipeline is basically showing them the secrets that pipeline uses.

Andres Pineros made changes - 2018-03-19 00:34

Description

Original: A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret.

For this use case, withCredentials is broken:
{code:java}
node {
stage('Break Security') {
withCredentials([string(credentialsId: 'AWS_DEFAULT_REGION', variable: 'AWS_DEFAULT_REGION'),
string(credentialsId: 'AWS_ACCESS_KEY_ID', variable: 'AWS_ACCESS_KEY_ID'),
string(credentialsId: 'AWS_SECRET_ACCESS_KEY', variable: 'AWS_SECRET_ACCESS_KEY')]) {
def exposedSecret = ""
for(letter in env.AWS_DEFAULT_REGION) {
exposedSecret = "$exposedSecret $letter"
}
echo "$exposedSecret"
}
}
}{code}
The secret can be easily viewed.

Letting someone work on a pipeline is basically showing them the secrets that pipeline uses.

New: A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret.

For this use case, withCredentials is broken:
{code:java}
node {
  stage('Break Security') {
    withCredentials([string(credentialsId: 'AWS_DEFAULT_REGION', variable: 'AWS_DEFAULT_REGION'),
    string(credentialsId: 'AWS_ACCESS_KEY_ID', variable: 'AWS_ACCESS_KEY_ID'),
    string(credentialsId: 'AWS_SECRET_ACCESS_KEY', variable: 'AWS_SECRET_ACCESS_KEY')]) {
      def exposedSecret = ""
      for(letter in env.AWS_DEFAULT_REGION) {
        exposedSecret = "$exposedSecret $letter"
      }
      echo "$exposedSecret"
    }
  }
}{code}
The secret can be easily viewed.

Letting someone work on a pipeline is basically showing them the secrets that pipeline uses.

Andres Pineros made changes - 2018-03-19 00:36

Description

Original: A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret.

For this use case, withCredentials is broken:
{code:java}
node {
  stage('Break Security') {
    withCredentials([string(credentialsId: 'AWS_DEFAULT_REGION', variable: 'AWS_DEFAULT_REGION'),
    string(credentialsId: 'AWS_ACCESS_KEY_ID', variable: 'AWS_ACCESS_KEY_ID'),
    string(credentialsId: 'AWS_SECRET_ACCESS_KEY', variable: 'AWS_SECRET_ACCESS_KEY')]) {
      def exposedSecret = ""
      for(letter in env.AWS_DEFAULT_REGION) {
        exposedSecret = "$exposedSecret $letter"
      }
      echo "$exposedSecret"
    }
  }
}{code}
The secret can be easily viewed.

Letting someone work on a pipeline is basically showing them the secrets that pipeline uses.

New: A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret.

For this use case, withCredentials is broken:
{code:java}
node {
  stage('Break Security') {
    withCredentials([string(credentialsId: 'AWS_DEFAULT_REGION', variable: 'AWS_DEFAULT_REGION'),
    string(credentialsId: 'AWS_ACCESS_KEY_ID', variable: 'AWS_ACCESS_KEY_ID'),
    string(credentialsId: 'AWS_SECRET_ACCESS_KEY', variable: 'AWS_SECRET_ACCESS_KEY')]) {
      def exposedSecret = ""
      for(letter in env.AWS_SECRET_ACCESS_KEY) {
        exposedSecret = "$exposedSecret $letter"
      }
      echo "$exposedSecret"
    }
  }
}{code}
The secret can be easily viewed.

Letting someone work on a pipeline is basically showing them the secrets that pipeline uses.
For this example I used "Secret Text", but it also happens with "AWS Credentials".

Andres Pineros made changes - 2018-03-19 01:33

Summary

Original: withCredentials step masking isn't secure

New: withCredentials step masking easily bypassed

Jesse Glick made changes - 2018-03-19 13:28

Remote Link

New: This issue links to "PR 49 (Web Link)" [ 20272 ]

Jesse Glick added a comment - 2018-03-19 13:31

The easier way is to run env | od -a, or post secrets to Twitter, or whatever.

A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret.

This is not a valid use case. If someone is permitted to write Pipeline script in a folder in which a given credentials item is in scope, they must be trusted to use those credentials properly. If you do not trust them, do not let them write Pipeline script (or, more generally, configure jobs).

Jesse Glick added a comment - 2018-03-19 13:31 The easier way is to run env | od -a , or post secrets to Twitter, or whatever. A very common use case of Jenkins is to delegate the responsibility of the creation of pipelines to third parties or developers. These external teams should be able to use secrets given to them via Jenkins credentials, but shouldn't be able to visualize the value of the secret. This is not a valid use case. If someone is permitted to write Pipeline script in a folder in which a given credentials item is in scope, they must be trusted to use those credentials properly. If you do not trust them, do not let them write Pipeline script (or, more generally, configure jobs).

Jesse Glick made changes - 2018-03-19 13:31

Resolution		New: Not A Defect [ 7 ]
Status	Original: Open [ 1 ]	New: Resolved [ 5 ]

SCM/JIRA link daemon added a comment - 2018-03-19 21:55

Code changed in jenkins
User: Jesse Glick
Path:
src/main/resources/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep/help.html
http://jenkins-ci.org/commit/credentials-binding-plugin/c7aff033605562a138d41c7b28b10e6812ee9111
Log:
~~JENKINS-50242~~ Improved help text to correct a misunderstanding.

SCM/JIRA link daemon added a comment - 2018-03-19 21:55

Code changed in jenkins
User: Jesse Glick
Path:
src/main/resources/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep/help.html
http://jenkins-ci.org/commit/credentials-binding-plugin/8a0039503c6b3b394277f67321f8c507cc240d25
Log:
Merge pull request #49 from jglick/help-~~JENKINS-50242~~

~~JENKINS-50242~~ Improved help text to correct a misunderstanding

Compare: https://github.com/jenkinsci/credentials-binding-plugin/compare/aeda5de425e4...8a0039503c6b

SCM/JIRA link daemon added a comment - 2018-03-19 21:55 Code changed in jenkins User: Jesse Glick Path: src/main/resources/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep/help.html http://jenkins-ci.org/commit/credentials-binding-plugin/8a0039503c6b3b394277f67321f8c507cc240d25 Log: Merge pull request #49 from jglick/help- JENKINS-50242 JENKINS-50242 Improved help text to correct a misunderstanding Compare: https://github.com/jenkinsci/credentials-binding-plugin/compare/aeda5de425e4...8a0039503c6b

Assignee:: Unassigned

Reporter:: Andres Pineros

Votes:: 0 Vote for this issue

Watchers:: 5 Start watching this issue

Created:: 2018-03-19 00:32

Updated:: 2020-02-29 08:34

Resolved:: 2018-03-19 13:31

Jenkins

Details

Description

Attachments

Issue Links

Activity

Collapse comment: Jesse Glick added a comment - 2018-03-19 13:31

Expand comment: Jesse Glick added a comment - 2018-03-19 13:31

Collapse comment: SCM/JIRA link daemon added a comment - 2018-03-19 21:55

Expand comment: SCM/JIRA link daemon added a comment - 2018-03-19 21:55

Collapse comment: SCM/JIRA link daemon added a comment - 2018-03-19 21:55

Expand comment: SCM/JIRA link daemon added a comment - 2018-03-19 21:55

People

Dates