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

Branch (or repo) specifiers are obfuscated with credentials (security implications)

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      If a branch (or repo) is named identically to a user id or password stored in credentials, Jenkins obfuscates the identifier in the logs. (ENV dump below.)

      GITREPO=git@github.foo.org:****/sample-project.git
      GIT_BRANCH=origin/***

      For example, my username/password combo stored in credentials is folly/isthisexample. Let's say I named my branch isthisexample, then the branch name would be obfuscated with four asterisks ('***') in logs. Similarly, assume my org is named folly, then a branch or org named folly also would be obfuscated in logs.

      Besides the obvious implications for debugging checkouts and branch detections, this is a clear security risk. If I know a username but I don't know a password, all I need to do is build a branch with my best guess, and Jenkins will tell me that my password guess is correct by showing me four stars. Similarly a validation is also offered for usernames.

      Proposed solution: Repo and branch identifiers are not run through an obfuscation filter. Moreover, ONLY the credential-specific pieces should be run through an obfuscation filter.

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            The git plugin and the git client plugin do not mask sensitive information. Masking is happening at a different level. I've removed the git plugin and git client plugin from the list of components.

            I believe that the Jenkins security team would advise that displaying a credential value in a console log and relying on masking to hide the credential value is prone to many forms of attack.

            For example, since the masking is likely applied to the entire console log, an attacker could echo the contents of a password guessing data file to the console log and watch for interesting output. No need to spend the effort creating branches, just list the contents of a file to the console log and see the results.

            Show
            markewaite Mark Waite added a comment - The git plugin and the git client plugin do not mask sensitive information. Masking is happening at a different level. I've removed the git plugin and git client plugin from the list of components. I believe that the Jenkins security team would advise that displaying a credential value in a console log and relying on masking to hide the credential value is prone to many forms of attack. For example, since the masking is likely applied to the entire console log, an attacker could echo the contents of a password guessing data file to the console log and watch for interesting output. No need to spend the effort creating branches, just list the contents of a file to the console log and see the results.
            Hide
            markewaite Mark Waite added a comment -

            I suspect that the plugin providing the masking is the "mask passwords" plugin.

            Show
            markewaite Mark Waite added a comment - I suspect that the plugin providing the masking is the "mask passwords" plugin.
            Hide
            danielbeck Daniel Beck added a comment -

            JENKINS-44860 would allow to prevent masking user names, which can be useful when they are service (~repo) specific and therefore identical to other common names.

            The solution for passwords is easy, don't use passwords so trivial they have a real chance to appear in the build log.

            Given multi-branch pipelines and similar setups that make org, repo, and branch names a structural part of the job name, there doesn't seem much benefit in special treatment for this very specific subset of output, as just echoing the job name would "unmask"the branch name anyway elsewhere.

            Show
            danielbeck Daniel Beck added a comment - JENKINS-44860 would allow to prevent masking user names, which can be useful when they are service (~repo) specific and therefore identical to other common names. The solution for passwords is easy, don't use passwords so trivial they have a real chance to appear in the build log. Given multi-branch pipelines and similar setups that make org, repo, and branch names a structural part of the job name, there doesn't seem much benefit in special treatment for this very specific subset of output, as just echoing the job name would "unmask"the branch name anyway elsewhere.
            Hide
            ingyhere John Engelke added a comment - - edited
            The solution for passwords is easy, don't use passwords so trivial. ...

            Easier said than done as it would require controlling users. I feel it also doesn't address the core issue, which is the sledgehammer approach to value masking, nor providing a testing mechanism on half the user/pass value.

            Given multi-branch pipelines and similar setups ... just echoing the job name would "unmask" the branch name anyway elsewhere.

            Are you sure? I tried echoing text containing the credential-matching text in the console and it came out obfuscated as four stars. I suspect echoing a different Jenkins variable with the same value would do the same. This also limits troubleshooting on more advanced operations that may require echoing to the console for such things as checking out multiple repos or any other situation where the values match an existing credential.

            JENKINS-44860 is close enough to call a duplicate, but I think it's senseless to only focus on usernames. It should be broadened and renamed to something like, "Disable masking of non-credential values. ..." The real fix is to surgically apply masking where it is supposed to be applied.

            At least this will be indexed in search engines so someone banging a head against the wall can tie back the issue more broadly to an existing bug report.

            Show
            ingyhere John Engelke added a comment - - edited The solution for passwords is easy, don't use passwords so trivial. ... Easier said than done as it would require controlling users. I feel it also doesn't address the core issue, which is the sledgehammer approach to value masking, nor providing a testing mechanism on half the user/pass value. Given multi-branch pipelines and similar setups ... just echoing the job name would "unmask" the branch name anyway elsewhere. Are you sure? I tried echoing text containing the credential-matching text in the console and it came out obfuscated as four stars. I suspect echoing a different Jenkins variable with the same value would do the same. This also limits troubleshooting on more advanced operations that may require echoing to the console for such things as checking out multiple repos or any other situation where the values match an existing credential. JENKINS-44860 is close enough to call a duplicate, but I think it's senseless to only focus on usernames. It should be broadened and renamed to something like, "Disable masking of non-credential values. ..." The real fix is to surgically apply masking where it is supposed to be applied. At least this will be indexed in search engines so someone banging a head against the wall can tie back the issue more broadly to an existing bug report.
            Hide
            danielbeck Daniel Beck added a comment - - edited

            Are you sure? I tried echoing text containing the credential-matching text in the console and it came out obfuscated as four stars. I suspect echoing a different Jenkins variable with the same value would do the same

            To clarify, I meant that all instances would be **** out, but since anyone looking at the build log would know the job name, it would then reveal whatever was masked, similar to your "branch name" example.

            Easier said than done as it would require controlling users.

            I feel like you probably have bigger problems than build output masking if that's the cause.

            I feel it also doesn't address the core issue, which is the sledgehammer approach to value masking, nor providing a testing mechanism on half the user/pass value.

            WDYM by 'testing'?

            I can see an argument for certain build operations being exempt from masking, but in this case the problem seems to be shell script output. That's the part most likely to disclose secrets accidentally, an env or set call (in Batch) would do it, despite the author just wanting to log the build environment.


            Please also note that for the case of your example:

            If I know a username but I don't know a password, all I need to do is build a branch with my best guess, and Jenkins will tell me that my password guess is correct by showing me four stars. Similarly a validation is also offered for usernames.

            If your expectation is that someone can be a committer to your project (they can define branch names) that is built with credentials being defined and could not take an action that would reveal the password, that is fairly unrealistic. They can just change the Jenkinsfile, pom.xml, build.gradle, or just write a test that always writes all env vars to stderr in a scrambled form (base64, rot13) that escapes masking.

            Show
            danielbeck Daniel Beck added a comment - - edited Are you sure? I tried echoing text containing the credential-matching text in the console and it came out obfuscated as four stars. I suspect echoing a different Jenkins variable with the same value would do the same To clarify, I meant that all instances would be **** out, but since anyone looking at the build log would know the job name, it would then reveal whatever was masked, similar to your "branch name" example. Easier said than done as it would require controlling users. I feel like you probably have bigger problems than build output masking if that's the cause. I feel it also doesn't address the core issue, which is the sledgehammer approach to value masking, nor providing a testing mechanism on half the user/pass value. WDYM by 'testing'? I can see an argument for certain build operations being exempt from masking, but in this case the problem seems to be shell script output. That's the part most likely to disclose secrets accidentally, an env or set call (in Batch) would do it, despite the author just wanting to log the build environment. Please also note that for the case of your example: If I know a username but I don't know a password, all I need to do is build a branch with my best guess, and Jenkins will tell me that my password guess is correct by showing me four stars. Similarly a validation is also offered for usernames. If your expectation is that someone can be a committer to your project (they can define branch names) that is built with credentials being defined and could not take an action that would reveal the password, that is fairly unrealistic. They can just change the Jenkinsfile, pom.xml, build.gradle, or just write a test that always writes all env vars to stderr in a scrambled form (base64, rot13) that escapes masking.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              ingyhere John Engelke
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: