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

Externals With(out) additional credentials is not clear

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: subversion-plugin
    • Labels:
    • Environment:
      Subversion Plugin 2.5.3
    • Similar Issues:

      Description

      The current way of authentification for external references in a project is not clear.
      See the extended discussion in JENKINS-22542

      We specify Credentials to use for check out. With these credentials you have complete (read-only) access to the project and its externals. (project and externals are in the same repository).
      Why do we need to specify these same credentials again just to get the change log?
      For security? but the check out is already successful.

      Dave (our evil developer) can add an external to SecretProjectC to projectA.
      Dave can no longer do a complete checkout locally as he has no access to projectC.
      When the build server has access (svn user Jenkins with global read only access)
      Now the build server can access SecretProjectC (because another external in projectA requires the additional credentials).

      So you rely on having configured exluded svn user Jenkins from secret projects.
      In which case the checkout already fails, as this requires additional credentials which Dave (hopefully) cannot configure in the build server.

      I suggest to
      1: remove the need for additional credentials when all items in a project require the same credentials.
      2: Make he selection of credentials a drop down without the need to type the realm (as the realm is already encoded in the credentials.
      Edit: second option removed as the 'encoded realm' is only a comment

        Attachments

          Issue Links

            Activity

            Hide
            danielbeck Daniel Beck added a comment - - edited

            1: remove the need for additional credentials when all items in a project require the same credentials.

            Stephen Connolly explained somewhere in this Jira that malicious SCM committers can point externals to a server they control to syphon off the credentials used by Jenkins.

            Quoting https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

            they can be a route to hijacking credentials that in most cases have full read access to the entire repository and not just the limited subset of the repository that an individual committer's credentials may have read access to. The recommended way to handle externals is to add those as additional modules directly. Thus ensuring that even if a committers machine is hacked or otherwise compromised, their credentials cannot be used to commit a modified build script and svn:external definition that allows the entire contents of the Subversion repository to be zipped up and FTP'd to a remote server)


            2: Make he selection of credentials a drop down without the need to type the realm (as the realm is already encoded in the credentials.

            I don't understand what you mean. The comment added in the 1.x to 2.x credential migration is entirely optional and has no meaning besides UI use, and the credentials domains are completely unrelated.

            Show
            danielbeck Daniel Beck added a comment - - edited 1: remove the need for additional credentials when all items in a project require the same credentials. Stephen Connolly explained somewhere in this Jira that malicious SCM committers can point externals to a server they control to syphon off the credentials used by Jenkins. Quoting https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin they can be a route to hijacking credentials that in most cases have full read access to the entire repository and not just the limited subset of the repository that an individual committer's credentials may have read access to. The recommended way to handle externals is to add those as additional modules directly. Thus ensuring that even if a committers machine is hacked or otherwise compromised, their credentials cannot be used to commit a modified build script and svn:external definition that allows the entire contents of the Subversion repository to be zipped up and FTP'd to a remote server) 2: Make he selection of credentials a drop down without the need to type the realm (as the realm is already encoded in the credentials. I don't understand what you mean. The comment added in the 1.x to 2.x credential migration is entirely optional and has no meaning besides UI use, and the credentials domains are completely unrelated.
            Hide
            renea Rene Affourtit added a comment - - edited

            2: Make he selection of credentials a drop down...
            The comment added (...) is entirely optional and has no meaning besides UI use (...)
            During my investigations I found that out too,
            I assumed that because the comment is an exact match of the credential domain, the domain was encoded in the credential. However, this is a value which can be modified by the user and is not suitable for looking up credentials for a specific domain.


            1: My 'problem' is that in subversion 2.4.x we needed to specify only one set of credential, but now we need to re-specify the same credentials.
            in a way which is not clear enough judging by the number of issues being reported (29237, 29225, 29211, just judging by the descriptions) (Edit, I stand corrected, these are separate issues)
            The described route to hijacking still exists (and will always exist when there is a single with global read-only access).
            I'm wondering what the added security is.
            Yes, when 'dave' adds an external to DavesFakeServer he should not receive the company credentials.
            But what happens during a check-out? (the actual check out is successful)

            ...

            Show
            renea Rene Affourtit added a comment - - edited 2: Make he selection of credentials a drop down... The comment added (...) is entirely optional and has no meaning besides UI use (...) During my investigations I found that out too, I assumed that because the comment is an exact match of the credential domain, the domain was encoded in the credential. However, this is a value which can be modified by the user and is not suitable for looking up credentials for a specific domain. 1: My 'problem' is that in subversion 2.4.x we needed to specify only one set of credential, but now we need to re-specify the same credentials. in a way which is not clear enough judging by the number of issues being reported (29237, 29225, 29211, just judging by the descriptions) (Edit, I stand corrected, these are separate issues) The described route to hijacking still exists (and will always exist when there is a single with global read-only access). I'm wondering what the added security is. Yes, when 'dave' adds an external to DavesFakeServer he should not receive the company credentials. But what happens during a check-out? (the actual check out is successful) ...
            Hide
            danielbeck Daniel Beck added a comment -

            I'm wondering what the added security is.

            You can choose to not support externals in your instance and require those locations be configured in the job instead.

            I wonder whether that would be sufficient; so that any credentials configured for a location will also be used for its externals, if we're not ignoring them.

            Show
            danielbeck Daniel Beck added a comment - I'm wondering what the added security is. You can choose to not support externals in your instance and require those locations be configured in the job instead. I wonder whether that would be sufficient; so that any credentials configured for a location will also be used for its externals, if we're not ignoring them.
            Hide
            danielbeck Daniel Beck added a comment -

            Stephen Connolly Wouldn't it suffice to prevent the evil scenario of hijacked externals to just ignore externals? This way, Jenkins could reuse the same credential used for the repository for the external, making configuration less of a hassle, and paranoid users could choose to not support externals at all.

            Show
            danielbeck Daniel Beck added a comment - Stephen Connolly Wouldn't it suffice to prevent the evil scenario of hijacked externals to just ignore externals? This way, Jenkins could reuse the same credential used for the repository for the external, making configuration less of a hassle, and paranoid users could choose to not support externals at all.
            Hide
            stephenconnolly Stephen Connolly added a comment -

            If we have ignoreExternals enabled by default and display a warning when you turn it off, then it might be acceptible... but better would be a check box to allow using credentials for externals and display a warning if you turn it on

            Show
            stephenconnolly Stephen Connolly added a comment - If we have ignoreExternals enabled by default and display a warning when you turn it off, then it might be acceptible... but better would be a check box to allow using credentials for externals and display a warning if you turn it on
            Hide
            estyrke Emil Styrke added a comment -

            I don't ever want to send any credentials to a server other than the one I've specified for the main repository, while still automatically fetching externals from that same server. Is there some technical limitation preventing this, or is there another security problem there that I don't see?

            Basically, what I propose is the same as "1: remove the need for additional credentials when all items in a project require the same credentials.", but with the added restriction that all items must originate from the same subversion server:

            3: remove the need for additional credentials when all items in a project are served by the same server and require the same credentials.

            Show
            estyrke Emil Styrke added a comment - I don't ever want to send any credentials to a server other than the one I've specified for the main repository, while still automatically fetching externals from that same server. Is there some technical limitation preventing this, or is there another security problem there that I don't see? Basically, what I propose is the same as "1: remove the need for additional credentials when all items in a project require the same credentials.", but with the added restriction that all items must originate from the same subversion server: 3: remove the need for additional credentials when all items in a project are served by the same server and require the same credentials.
            Hide
            renea Rene Affourtit added a comment -

            Emil Styrke As far as I understand it this is exactly what the credentials system is for.
            Server A asking for authentication is different credentials then server B.
            I'm not deep enough into the details to know if it is possible to fake the server id on which the credentials are chosen .

            So when someone adds an external to EvilServer with the intention to intercept your password you get the failure 'no credential to try' without the credentials for server A and B being tried.

            When you DO need a repository over multiple servers, this is where the additional credentials option is intended for.

            Show
            renea Rene Affourtit added a comment - Emil Styrke As far as I understand it this is exactly what the credentials system is for. Server A asking for authentication is different credentials then server B. I'm not deep enough into the details to know if it is possible to fake the server id on which the credentials are chosen . So when someone adds an external to EvilServer with the intention to intercept your password you get the failure 'no credential to try' without the credentials for server A and B being tried. When you DO need a repository over multiple servers, this is where the additional credentials option is intended for.
            Hide
            tkrah Torsten Krah added a comment -

            Confusing stuff here mixed. Imho if the external is pointing to the same configured server from which the checkout did start (and where the external are already followed and checked out) the changelog generation should not fail because i did not specify the same credentials in the additional section, do we have a consensus about this particular scenario - it may be differently judged in other scenarios?

            Show
            tkrah Torsten Krah added a comment - Confusing stuff here mixed. Imho if the external is pointing to the same configured server from which the checkout did start (and where the external are already followed and checked out) the changelog generation should not fail because i did not specify the same credentials in the additional section, do we have a consensus about this particular scenario - it may be differently judged in other scenarios?
            Hide
            splashnenen Alexandre Aubert added a comment -

            Hi,
            Any update on this ? Torsten Krah based on the scenario you describe, could we imagine to get a fix ? thanks a lot for your contribution on this topic (which started months ago !).

            Show
            splashnenen Alexandre Aubert added a comment - Hi, Any update on this ? Torsten Krah based on the scenario you describe, could we imagine to get a fix ? thanks a lot for your contribution on this topic (which started months ago !).
            Hide
            tkrah Torsten Krah added a comment -

            Alexandre Aubert - i wonder this myself. At least until now no one from the jenkins people involved with that has get to this and did leave some comment or proposal about it, too bad - seems to be not much interest in getting this fixed. I did not yet have a look on the code base if it would be easy or not to provide a patch - but without getting this sorted out if and how it should be fixed i won't even consider starting it.

            Show
            tkrah Torsten Krah added a comment - Alexandre Aubert - i wonder this myself. At least until now no one from the jenkins people involved with that has get to this and did leave some comment or proposal about it, too bad - seems to be not much interest in getting this fixed. I did not yet have a look on the code base if it would be easy or not to provide a patch - but without getting this sorted out if and how it should be fixed i won't even consider starting it.

              People

              • Assignee:
                recena Manuel Recena Soto
                Reporter:
                renea Rene Affourtit
              • Votes:
                19 Vote for this issue
                Watchers:
                22 Start watching this issue

                Dates

                • Created:
                  Updated: