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

Credentials Binding Plugin 1.23 $$ SECURITY-1835

    Details

    • Similar Issues:

      Description

      Regarding this: https://www.jenkins.io/security/advisory/2020-05-06/#SECURITY-1835

      Jenkins pipeline, using jenkinsfile, Credentials Binding Plugin 1.23 and Jenkins War 2.176.2 or 2.222.3. - password is not fully masking the log output password in contradiction to the security notes, when the password contains:  

      abc123$$

      abc$$123

      The result that is exposed in the log output, is (we expect it to be fully masked): 

      abc123

      abc

      Our linux system uses UTF-8, but we added -Dfile.encoding=UTF-8 to the jvm arguments to be sure jenkins was using it.  If escaped, the password is concealed in the logs, however we manage a large opensource Jenkins community privately within the corporation and are concerned about any unknown possible security leaks of people unknowingly not escaping their passwords.  Please clarify:  Is the plugin strictly requiring escaped $$ in the password? Or is the plugin expected to mask all passwords regardless of escaping $$'s?  If the latter, then we are still experiencing a bug. 

       

      SECURITY-1835 / CVE-2020-2182
      Credentials Binding Plugin allows specifying passwords and other secrets as environment variables, and will hide them from console output in builds. As a side effect of the fix for SECURITY-698$ characters in secrets are escaped to $$. This will then be expanded to $ again once the secret is passed to (post) build steps.
      Credentials Binding Plugin 1.22 and earlier does not mask the escaped form of the secret (containing $$). This occurs for example in the "Execute Maven top-level targets" build step included in Jenkins.
      Credentials Binding Plugin 1.23 now masks secrets both in their original form and with escaped $ characters so they will be masked even if printed before value expansion.

        Attachments

          Issue Links

            Activity

            Hide
            ts3648 Ted Sanders added a comment -

            We found the root cause - it is not related to the Credentials Binding Plugin.  The Credentials Binding Plugin snippet generator sidebar notes (question mark bubble) provided clarification.  We were using double quotes in the jenkinsfile instead of single quotes. This ticket can be closed. 

             

            Allows various kinds of credentials (secrets) to be used in idiosyncratic ways. (Some steps explicitly ask for credentials of a particular kind, usually as a credentialsId parameter, in which case this step is unnecessary.) Each binding will define an environment variable active within the scope of the step. You can then use them directly from any other steps that expect environment variables to be set:
             {{node {
            withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) { sh ''' set +x curl -u "$USERPASS" https://private.server/ > output ''' }

            }}}
            As another example (use Snippet Generator to see all options):
             {{node {
            withCredentials([string(credentialsId: 'mytoken', variable: 'TOKEN')])

            { sh ''' set +x curl -H "Token: $TOKEN" https://some.api/ ''' }

            }}}
            Note the use of single quotes to define the script (implicit parameter to sh) in Groovy above. You want the secret to be expanded by the shell as an environment variable. The following idiom is potentially less secure, as the secret is interpolated by Groovy and so (for example) typical operating system process listings will accidentally disclose it:
             {{node {
            withCredentials([string(credentialsId: 'mytoken', variable: 'TOKEN')])

            { sh /* WRONG! */ """ set +x curl -H 'Token: $TOKEN' https://some.api/ """ }

            }}}
            At least on Linux, environment variables can be obtained by other processes running in the same account, so you should not run a job which uses secrets on the same node as a job controlled by untrusted parties. In any event, you should always prefer expansion as environment variables to inclusion in the command, since Jenkins visualizations such as Blue Ocean will attempt to detect step parameters containing secrets and refuse to display them.
            The secret(s) will be masked (****) in case they are printed to the build log. This prevents you from accidentally disclosing passwords and the like via the log. (Bourne shell set +x, or Windows batch @echo off, blocks secrets from being displayed in echoed commands; but build tools in debug mode might dump all environment variables to standard output/error, or poorly designed network clients might display authentication, etc.) The masking could of course be trivially circumvented; anyone permitted to configure a job or define Pipeline steps is assumed to be trusted to use any credentials in scope however they like.
            Beware that certain tools mangle secrets when displaying them. As one example, Bash (as opposed to Ubuntu’s plainer Dash) does so with text containing ' in echo mode:

            Show
            ts3648 Ted Sanders added a comment - We found the root cause - it is not related to the Credentials Binding Plugin.  The Credentials Binding Plugin snippet generator sidebar notes (question mark bubble) provided clarification.  We were using double quotes in the jenkinsfile instead of single quotes. This ticket can be closed.    Allows various kinds of credentials (secrets) to be used in idiosyncratic ways. (Some steps explicitly ask for credentials of a particular kind, usually as a  credentialsId  parameter, in which case this step is unnecessary.) Each binding will define an environment variable active within the scope of the step. You can then use them directly from any other steps that expect environment variables to be set:  {{node { withCredentials( [usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')] ) { sh ''' set +x curl -u "$USERPASS" https://private.server/ > output ''' } }}} As another example (use  Snippet Generator  to see all options):  {{node { withCredentials( [string(credentialsId: 'mytoken', variable: 'TOKEN')] ) { sh ''' set +x curl -H "Token: $TOKEN" https://some.api/ ''' } }}} Note the use of  single  quotes to define the  script  (implicit parameter to  sh ) in Groovy above. You want the secret to be expanded by the shell as an environment variable. The following idiom is potentially less secure, as the secret is interpolated by Groovy and so (for example) typical operating system process listings will accidentally disclose it:  {{node { withCredentials( [string(credentialsId: 'mytoken', variable: 'TOKEN')] ) { sh /* WRONG! */ """ set +x curl -H 'Token: $TOKEN' https://some.api/ """ } }}} At least on Linux, environment variables can be obtained by other processes running in the same account, so you should not run a job which uses secrets on the same node as a job controlled by untrusted parties. In any event, you should always prefer expansion as environment variables to inclusion in the command, since Jenkins visualizations such as Blue Ocean will  attempt  to detect step parameters containing secrets and refuse to display them. The secret(s) will be masked ( **** ) in case they are printed to the build log. This prevents you from  accidentally  disclosing passwords and the like via the log. (Bourne shell  set +x , or Windows batch  @echo off , blocks secrets from being displayed in echoed commands; but build tools in debug mode might dump all environment variables to standard output/error, or poorly designed network clients might display authentication, etc.) The masking could of course be trivially circumvented; anyone permitted to configure a job or define Pipeline steps is assumed to be trusted to use any credentials in scope however they like. Beware that certain tools mangle secrets when displaying them. As one example, Bash (as opposed to Ubuntu’s plainer Dash) does so with text containing  '  in echo mode:

              People

              • Assignee:
                Unassigned
                Reporter:
                ts3648 Ted Sanders
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: