-
Bug
-
Resolution: Not A Defect
-
Major
-
None
-
Jenkins: 2.111
Plugin: 1.15
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
- mentioned in
-
Page Failed to load
[JENKINS-50242] withCredentials step masking easily bypassed
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. |
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. |
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". |
Summary | Original: withCredentials step masking isn't secure | New: withCredentials step masking easily bypassed |
Remote Link | New: This issue links to "PR 49 (Web Link)" [ 20272 ] |
Resolution | New: Not A Defect [ 7 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Remote Link | New: This issue links to "Page (Jenkins Wiki)" [ 20282 ] |
Remote Link | Original: This issue links to "Page (Jenkins Wiki)" [ 20282 ] | New: This issue links to "Page (Jenkins Wiki)" [ 20282 ] |
Link |
New:
This issue is duplicated by |
Link |
New:
This issue relates to |