• Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Major 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".

          [JENKINS-50242] withCredentials step masking easily bypassed

          Andres Pineros created issue -
          Andres Pineros made changes -
          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 -
          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 -
          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 -
          Summary Original: withCredentials step masking isn't secure New: withCredentials step masking easily bypassed
          Jesse Glick made changes -
          Remote Link New: This issue links to "PR 49 (Web Link)" [ 20272 ]
          Jesse Glick made changes -
          Resolution New: Not A Defect [ 7 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          Jesse Glick made changes -
          Remote Link New: This issue links to "Page (Jenkins Wiki)" [ 20282 ]
          Jesse Glick made changes -
          Remote Link Original: This issue links to "Page (Jenkins Wiki)" [ 20282 ] New: This issue links to "Page (Jenkins Wiki)" [ 20282 ]
          Kalle Niemitalo made changes -
          Link New: This issue is duplicated by JENKINS-60962 [ JENKINS-60962 ]
          Kalle Niemitalo made changes -
          Link New: This issue relates to JENKINS-54538 [ JENKINS-54538 ]

            Unassigned Unassigned
            apineros Andres Pineros
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: