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

GitHub branch source 2.5.5 & newer ignore domain limited credentials when scanning

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Trivial
    • Resolution: Fixed
    • Labels:
      None
    • Environment:
      Jenkins 2.176.2
      GitHub Branch Source plugin 2.5.6
      Git plugin 3.12.0
    • Similar Issues:

      Description

      The GitHub branch source plugin uses the GitHub REST API to scan remote repositories for changes. I had incorrectly defined my GitHub credential in a credential domain that only included the github.com domain. The GitHub branch source plugin allowed me to select that credential, but then would not use that credential because it was making the request to api.github.com rather than github.com.

      My working credential domains had defined the domain as github.com,*.github.com. That working definition matched api.github.com.

      My incorrect credential domain was specified as only including github.com. With that incorrect domain specificiation, the repository scan log would report:

      Started
      [Tue Aug 20 13:00:40 MDT 2019] Starting branch indexing...
      13:00:40 Connecting to https://api.github.com with no credentials, anonymous access
      

      Without the credentials, scanning of private repositories is not allowed and scanning of public repositories is limited by a much smaller value for the GitHub API rate limit.

      Version Result
      2.5.6 Credentials ignored if assigned incorrect domain
      2.5.5 Credentials ignored if assigned incorrect domain
      2.5.4 Credentials honored if assigned incorrect domain
      2.5.3 Credentials honored if assigned incorrect domain
      2.4.5 Credentials honored if assigned incorrect domain
      2.3.6 Credentials honored if assigned incorrect domain

      Refer to the JENKINS-59016 branch in my jenkins-bugs repo for the Jenkins Pipeline that I use to test this. The jobs are run from inside a Docker image that I use which includes credentials used to access the repository.

      Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential. Beginning with GitHub branch source 2.5.5, the credential domain also controls job internal visibility of the credential.

        Attachments

          Activity

          Hide
          bitwiseman Liam Newman added a comment -

          For anyone, looking at the comments (and not the full history view), Mark helped us analyze this issue and then updated the description.  Same people are likely to be the ones to work on this further, but the regression is much lower priority/severity that initially thought. 

           

          Show
          bitwiseman Liam Newman added a comment - For anyone, looking at the comments (and not the full history view), Mark helped us analyze this issue and then updated the description.  Same people are likely to be the ones to work on this further, but the regression is much lower priority/severity that initially thought.   
          Hide
          teilo James Nord added a comment -

          this causes lots of confusion when the credential works for an organisation folder (scanning all of github) and then the scan of the actual repo does not and falls back to anonymous.

          eg.

          [Thu Mar 19 11:12:10 UTC 2020] Updating actions...
          Looking up details of myghorg...
          Organization URL: CloudBees
          [Thu Mar 19 11:12:10 UTC 2020] Consulting GitHub Organization
          11:12:10 Connecting to https://api.github.com using my-credential/****** (PAT token for GitHub)
          11:12:10 Looking up repositories of organization myghorg
          Ignoring wibble
          Ignoring bar
          Ignoring foo
          ...
          ignoring silly-name
          Proposing some-repo
          11:13:21 GitHub API Usage: Current quota has 59 remaining (5 under budget). Next quota of 60 in 1 hr 0 min
          11:13:22 Connecting to https://api.github.com with no credentials, anonymous access
          ERROR: [Thu Mar 19 11:13:22 UTC 2020] Could not fetch sources from navigator org.jenkinsci.plugins.github_branch_source.GitHubSCMNavigator@7cf2c1ef

          I beleive the scanning is done by the same plugin - which is why this is just confusing.

          > Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential

          that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this.

          Show
          teilo James Nord added a comment - this causes lots of confusion when the credential works for an organisation folder (scanning all of github) and then the scan of the actual repo does not and falls back to anonymous. eg. [Thu Mar 19 11:12:10 UTC 2020] Updating actions... Looking up details of myghorg... Organization URL: CloudBees [Thu Mar 19 11:12:10 UTC 2020] Consulting GitHub Organization 11:12:10 Connecting to https://api.github.com using my-credential/****** (PAT token for GitHub) 11:12:10 Looking up repositories of organization myghorg Ignoring wibble Ignoring bar Ignoring foo ... ignoring silly-name Proposing some-repo 11:13:21 GitHub API Usage: Current quota has 59 remaining (5 under budget). Next quota of 60 in 1 hr 0 min 11:13:22 Connecting to https://api.github.com with no credentials, anonymous access ERROR: [Thu Mar 19 11:13:22 UTC 2020] Could not fetch sources from navigator org.jenkinsci.plugins.github_branch_source.GitHubSCMNavigator@7cf2c1ef I beleive the scanning is done by the same plugin - which is why this is just confusing. > Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this.
          Hide
          bitwiseman Liam Newman added a comment -

          James Nord

          > Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential

          that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this.

          Not according to the documentation: 

          The use-case for credentials domains is to provide a way for the user to provide information about the services with which the credentials are expected to work.
          Credential domains are intended to help select correct credentials for each services.

           
          Credential domains are not intended to prevent credentials from being used against the wrong services.

           
          In some cases, the domain requirements of a credential cannot be determined, such as when using a credentials parameter or when using a plugin that has not fully implemented the recommendations of the consumer guide.
           

          In order to ensure that users can actually select the required credentials in these cases, the Credentials API needs to return credentials from all domains, which is why we use Excluding credentials from domains that do not match.
           

          Because of the above: Credential domains are not intended to restrict access to credentials.

          https://github.com/jenkinsci/credentials-plugin/blob/master/docs/user.adoc

           

           

          Show
          bitwiseman Liam Newman added a comment - James Nord > Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this. Not according to the documentation:  The use-case for credentials domains is to provide a way for the user to provide information about the services with which the credentials are expected to work. Credential domains are intended to help select correct credentials for each services.   Credential domains are not intended to prevent credentials from being used against the wrong services.   In some cases, the domain requirements of a credential cannot be determined, such as when using a credentials parameter or when using a plugin that has not fully implemented the recommendations of the  consumer guide .   In order to ensure that users can actually select the required credentials in these cases, the Credentials API needs to return credentials from all domains, which is why we use  Excluding credentials from domains that do not match .   Because of the above:  Credential domains are not intended to restrict access to credentials. https://github.com/jenkinsci/credentials-plugin/blob/master/docs/user.adoc    
          Hide
          teilo James Nord added a comment -

          > In some cases, the domain requirements of a credential cannot be determined, such as when using a credentials parameter or when using a plugin that has not fully implemented the recommendations of the consumer guide.

           

          Yes - and not implementing the consumer guide correctly is a bug, credentials being security sensitive makes it a security bug.

          Show
          teilo James Nord added a comment - > In some cases, the domain requirements of a credential cannot be determined, such as when using a credentials parameter or when using a plugin that has not fully implemented the recommendations of the  consumer guide .   Yes - and not implementing the consumer guide correctly is a bug, credentials being security sensitive makes it a security bug.
          Hide
          bitwiseman Liam Newman added a comment - - edited

          > Credential domains are not intended to prevent credentials from being used against the wrong services.

          > Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this.

          Okay, I get it.
          Since this plugin is refusing to use a credential that is in the wrong domain, it is a incorrect behavior related to credentials. Thus a security issue.

          Now what? Does this move into the SECURITY JIRA and get prioritized against other security issues?

          Show
          bitwiseman Liam Newman added a comment - - edited > Credential domains are not intended to prevent credentials from being used against the wrong services. > Credential domains usually only control user interface visibility of the credential, not job internal visibility of the credential that should never be the case, where it is it is a security issue in the plugins that do that - please file them if you know of this. Okay, I get it. Since this plugin is refusing to use a credential that is in the wrong domain, it is a incorrect behavior related to credentials. Thus a security issue. Now what? Does this move into the SECURITY JIRA and get prioritized against other security issues?
          Hide
          teilo James Nord added a comment -

          Okay, I get it.
          Since this plugin is refusing to use a credential that is in the wrong domain, it is a incorrect behavior related to credentials. Thus a security issue.

          refusing to use a credential that is in the wrong domain is the correct behaviour.

          knowingly using a credential that is in a domain that does not match is a security issue as it could lead to credential leaking.

          if you know if a plugging that fits that please raise a security issue for discussion

           

          Show
          teilo James Nord added a comment - Okay, I get it. Since this plugin is refusing to use a credential that is in the wrong domain, it is a incorrect behavior related to credentials. Thus a security issue. refusing to use a credential that is in the wrong domain is the correct behaviour. knowingly using a credential that is in a domain that does not match is a security issue as it could lead to credential leaking. if you know if a plugging that fits that please raise a security issue for discussion  
          Hide
          bitwiseman Liam Newman added a comment -

          > refusing to use a credential that is in the wrong domain is the correct behaviour

          So, this plugin is doing the right thing then?
          What are you trying to say? That this isn't bug but correct behavior? I'm so confused.

          Show
          bitwiseman Liam Newman added a comment - > refusing to use a credential that is in the wrong domain is the correct behaviour So, this plugin is doing the right thing then? What are you trying to say? That this isn't bug but correct behavior? I'm so confused.
          Hide
          teilo James Nord added a comment -

          read my first comment again and look closely at the log snippet.

           

          The plugin is simultaneously correct and incorrect, Schroedinger would be proud.

          When performing the org scan it is appearing to allow invalid credentials to be used.  when examining the individual repo that same credential is now (correctly?) not used.

          given all calls should be to the same host (API.github.com in this case) there should be no reason why the credential is valid for one but not the other.

          this behaviour  is at best confusing as heck.

           

           

          Show
          teilo James Nord added a comment - read my first comment again and look closely at the log snippet.   The plugin is simultaneously correct and incorrect, Schroedinger would be proud. When performing the org scan it is appearing to allow invalid credentials to be used.  when examining the individual repo that same credential is now (correctly?) not used. given all calls should be to the same host (API.github.com in this case) there should be no reason why the credential is valid for one but not the other. this behaviour  is at best confusing as heck.    

            People

            Assignee:
            jtaboada Jose Blas Camacho Taboada
            Reporter:
            markewaite Mark Waite
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: