Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59214

BlueOcean UI and pipeline steps view (FlowGraphTable ) reveal sensitive data

      When utilizing the "Mask Passwords Plugin" https://wiki.jenkins.io/display/JENKINS/Mask+Passwords+Plugin

      In a Jenkins Pipeline Job as follows:

      vaultlookupsecret = 'mysupersekr3tp@sswordstuffz'
      
      wrap([$class: 'MaskPasswordsBuildWrapper', varPasswordPairs: [[var: 'vaultlookupsecret', password: vaultlookupsecret]], varMaskRegexes: []]) {
      
        script{
          mystuff = sh(script: "/bin/bash script.sh -p \"${vaultlookupsecret}\" > output_upload.txt", returnStatus: true).toString().trim()
        }
      }
      

      Within the "normal" jenkins job logs - this is properly masked as expected- and appears as follows:

      + /bin/bash script.sh -p ********

       

      When viewing these same log(s) in the "BlueOcean" Pane - the top level step displays the commandline including the password in plaintext. When selecting the "dropdown" on this item within blueocean - the log display(s) the same commandline with the properly "masked" data.

       

      Top Level/Label in Blue Ocean:

      /bin/bash script.sh -p mysupersekr3tp@sswordstuffz

       

      Drop-Down in Blue Ocean:

      + /bin/bash script.sh -p ********

       

      I'm not sure if there is some configuration i need to make within BlueOcean, but "normal" logs are masked properly, it is only "BlueOcean" logs which seem unmasked (even though when selecting the drop-down - the log is again masked.

       

      Version(s):

      Jenkins 2.176.1

      BlueOcean Plugin: 1.17.0

      Mask Passwords Plugin 2.12.0

       

      Note: I selected "componenets: core" as i "think" the BlueOcean Plugin is technically "core" now - and there isn't a component for "BlueOcean Specifically.

       

          [JENKINS-59214] BlueOcean UI and pipeline steps view (FlowGraphTable ) reveal sensitive data

          Simon O added a comment -

          Hi,

          I am facing the same issue but for me also the pipeline steps view (flowGraphTable) is affected and reveals all my sensitive data. I also tried using the log file filter plugin as well but the same behaviour could be observed.

          The issue can be explored by using the following pipeline snippet:

          node {

              def someSecret = "someSecret"

              wrap([$class: 'MaskPasswordsBuildWrapper', varPasswordPairs: [[password: someSecret]]])

          {         echo "Secret String: " + someSecret     }

          }

          The console + raw log is hiding the secret properly:

          Blue Ocean UI reveals the secret inside the header:

          Pipeline Steps View reveals secrets as well:

          Is there anything I am doing wrong here or is there another approach recommended for hiding sensitive data? Any help to solve the issue is highly appreciated.

          Best Regards,

          Simon

           

           

          Simon O added a comment - Hi, I am facing the same issue but for me also the pipeline steps view (flowGraphTable) is affected and reveals all my sensitive data. I also tried using the log file filter plugin as well but the same behaviour could be observed. The issue can be explored by using the following pipeline snippet: node {     def someSecret = "someSecret"     wrap([$class: 'MaskPasswordsBuildWrapper', varPasswordPairs: [ [password: someSecret] ]]) {         echo "Secret String: " + someSecret     } } The console + raw log is hiding the secret properly: Blue Ocean UI reveals the secret inside the header: Pipeline Steps View reveals secrets as well: Is there anything I am doing wrong here or is there another approach recommended for hiding sensitive data? Any help to solve the issue is highly appreciated. Best Regards, Simon    

          André Carmo added a comment -

          This is also happening with workflow-cps 2.87 and mask-passwords 2.13. This seems to be a huge security flaw which was somehow introduced in some recent update of workflow-cps. I'm actually surprised how not many more people are talking about this.

           

          Is there any workaround or the only solution is to downgrade workflow-cps?

          André Carmo added a comment - This is also happening with workflow-cps 2.87 and mask-passwords 2.13. This seems to be a huge security flaw which was somehow introduced in some recent update of workflow-cps. I'm actually surprised how not many more people are talking about this.   Is there any workaround or the only solution is to downgrade workflow-cps?

          Dileep Reddy added a comment -

          jlang1 Were u able to find some workaround for this?

          Facing same issue.

          Dileep Reddy added a comment - jlang1  Were u able to find some workaround for this? Facing same issue.

          remiwer715 added a comment -

          Hello there,

          This is quite a serius matter!!! Is anyone taking care of this???

          Credentials as parameters are displayed in plain text.

          password(defaultValue: '', description: 'Password', name: "pass"),

          Even if you mouseover the credentials are displayed in plaintext.

          Kind regards,

          JD

          remiwer715 added a comment - Hello there, This is quite a serius matter!!! Is anyone taking care of this??? Credentials as parameters are displayed in plain text. password(defaultValue: '', description: 'Password', name: "pass"), Even if you mouseover the credentials are displayed in plaintext. Kind regards, JD

          The workaround that my team used was to add the secret variables in a withEnv block like this:

          withEnv([PASSWORD=mypassword]) {
              sh echo $PASSWORD
          }
          

           

          This would stop the pipeline steps from showing the command and instead would just print "Shell Script". 

          This is a workaround - I really hope the team fix this soon as it is a big security flaw

          Pritam Sangani added a comment - The workaround that my team used was to add the secret variables in a withEnv block like this: withEnv([PASSWORD=mypassword]) {     sh echo $PASSWORD }   This would stop the pipeline steps from showing the command and instead would just print "Shell Script".  This is a workaround - I really hope the team fix this soon as it is a big security flaw

          pritam35 can you please describe your workaround with a bit more detail? I tried using withEnv inside the wrap() block and in the BlueOcean header the secret still shows up. It is however masked in the drop-down as well as the pipeline.log file under artifacts.

          Kote Mushegiani added a comment - pritam35 can you please describe your workaround with a bit more detail? I tried using withEnv inside the wrap() block and in the BlueOcean header the secret still shows up. It is however masked in the drop-down as well as the pipeline.log file under artifacts.

          I did manage to get this working using pritam35's suggestion. The trick is to use single-quotes per documentation spec here: jenkins.io/doc/pipeline/steps/credentials-binding/ Same logic with env variable interpolation seems to apply.

           

          Here's a working config that is masked both in logs and in the BlueOcean step header.

           

          token = "super-secret-sauce"
          final URL="https://${token}@url.io/"
          wrap([$class: 'MaskPasswordsBuildWrapper', varPasswordPairs: [[password: URL]]]) {            
              withEnv(["URL=${URL}"]) {
                  curlOut = this.sh(script: 'curl -s -w \"%{http_code}\" $URL', returnStdout:true)            
                  curlHttpCode=curlOut.replaceAll("\\s","").replaceAll("\\n|\\r","").replaceAll("\\{|\\}","")
                  echo curlHttpCode
                  assert curlHttpCode.equals("200")
              }
          }
          

           

           

          Kote Mushegiani added a comment - I did manage to get this working using pritam35 's suggestion. The trick is to use single-quotes per documentation spec here: jenkins.io/doc/pipeline/steps/credentials-binding/ Same logic with env variable interpolation seems to apply.   Here's a working config that is masked  both in logs and in the BlueOcean step header.   token = " super -secret-sauce" final URL= "https: //${token}@url.io/" wrap([$class: 'MaskPasswordsBuildWrapper' , varPasswordPairs: [[password: URL]]]) { withEnv([ "URL=${URL}" ]) { curlOut = this .sh(script: 'curl -s -w \ "%{http_code}\" $URL' , returnStdout: true ) curlHttpCode=curlOut.replaceAll( "\\s" , "").replaceAll(" \\n|\\r "," ").replaceAll(" \\{|\\} "," ") echo curlHttpCode assert curlHttpCode.equals( "200" ) } }    

          Liam Newman added a comment - - edited

          The documentation says it is not recommended to use groovy string interpolation with secrets. See JENKINS-47101. \

          If you follow that recommendation and use single-quotes string literals there is no issue.

          Liam Newman added a comment - - edited The documentation says it is not recommended to use groovy string interpolation with secrets . See JENKINS-47101 . \ If you follow that recommendation and use single-quotes string literals there is no issue.

          Windom WU added a comment -

          try to use groovy escape sign "\" in fornt of dollar sign in double quote content

          withCredentials(bindings: [certificate(credentialsId: 'jenkins-certificate-for-xyz', \
          keystoreVariable: 'CERTIFICATE_FOR_XYZ', \
          passwordVariable: 'XYZ-CERTIFICATE-PASSWORD')]) {

          sh """

          echo \${XYZ-CERTIFICATE-PASSWORD}

          """

          Windom WU added a comment - try to use groovy escape sign "\" in fornt of dollar sign in double quote content withCredentials(bindings: [certificate(credentialsId: 'jenkins-certificate-for-xyz', \ keystoreVariable: 'CERTIFICATE_FOR_XYZ', \ passwordVariable: 'XYZ-CERTIFICATE-PASSWORD')]) { sh """ echo \${XYZ-CERTIFICATE-PASSWORD} """

          Vinícius added a comment -

          It seems that this issue is unresolved yet. Does this have any kind of workaround?

          Vinícius added a comment - It seems that this issue is unresolved yet. Does this have any kind of workaround?

            Unassigned Unassigned
            jlang1 Jason Lang
            Votes:
            18 Vote for this issue
            Watchers:
            22 Start watching this issue

              Created:
              Updated: