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

Credential handling should be more fine-grained

      We use:

      Jenkins 2.289.2

      Micro Focus Application Automation Plugin 6.9

       

      after installing your plugin, we are faced with a big security issue.

      in order to use the plugin we are required to enter ALL the users and their password in the Jenkins Configure System screen.

       

      this causes us:

      1. the need to have jenkins administrative access server to change/add/remove users.
      2. the need to have jenkins administrative access to change a password for a user.
      3. a problem in which any user with access to the jenkins server can choose any pre-defined user to access the ALM server (since it is configured in the server level, and not in the job level) - THIS IS THE SECURITY PROBLEM....

      I would expect you to use the credentials system embedded in the jenkins server in order to be able to receive the credentials on the job/script level (like almost any other plugin).

      this way:

      1. each user can only access the credentials he is allowed.
      2. each user can add/change/remove credentials without jenkins administrative privilege but only with credential privilege.
      3. other users in the system are not exposed to credentials they are not allowed to see.

       

      I'm available to provide any needed information regarding this issue.

       

          [JENKINS-66246] Credential handling should be more fine-grained

          To Jenkins Security Officer danielbeck: This issue seems to report a security problem but was not filed in the SECURITY project. I am not familiar with Micro Focus Application Automation Plugin myself and cannot say whether the concern is valid.

          Kalle Niemitalo added a comment - To Jenkins Security Officer danielbeck : This issue seems to report a security problem but was not filed in the SECURITY project. I am not familiar with Micro Focus Application Automation Plugin myself and cannot say whether the concern is valid.

          radislav added a comment -

          Hi

          The issue is following : plugin allows to define credentials in global configuration, and later those credentials might be used for job execution by all valid users.

          For some users - this scenario is valid and desired as only one person (administrator) is managing credentials.

          In this specific case, for this customer, using global credentials by any arbitrary (even authenticated)  user is not valid scenario, so he requires to allow definition of credentials in job level and not in global level. In this way. other users won't be able to re use his credentials.

          The problem here is more functional.

           

          So from "Jenkins" point of view - it is not required to handle it in security project.

           

          Thanks,

           

          radislav added a comment - Hi The issue is following : plugin allows to define credentials in global configuration, and later those credentials might be used for job execution by all valid users. For some users - this scenario is valid and desired as only one person (administrator) is managing credentials. In this specific case, for this customer, using global credentials by any arbitrary (even authenticated)  user is not valid scenario, so he requires to allow definition of credentials in job level and not in global level. In this way. other users won't be able to re use his credentials. The problem here is more functional.   So from "Jenkins" point of view - it is not required to handle it in security project.   Thanks,  

          radislav_berkovich Thank you for the explanation.

          Kalle Niemitalo added a comment - radislav_berkovich Thank you for the explanation.

          Amit Dar added a comment -

          radislav_berkovich is correct, the security breach is related to the functionality of the plugin and NOT to the functionality of the jenkins controller itself.

          kon, I'm sorry if the title of the issue s a bit misleading... for us, this a major problem...

          Amit Dar added a comment - radislav_berkovich  is correct, the security breach is related to the functionality of the plugin and NOT to the functionality of the jenkins controller itself. kon , I'm sorry if the title of the issue s a bit misleading... for us, this a major problem...

          Daniel Beck added a comment - - edited

          kon Thanks for the ping.


          While I don't understand exactly how this plugin works, many plugins set up "remote endpoints" of some sort with globally defined credentials for them to be referenced in jobs. That said, I would expect a dedicated "Jenkins user" to be specified to interact with HP ALM from Jenkins, but perhaps that's not possible? I tried the plugin and it's possible to specify multiple servers, each with multiple usernames/passwords. Why that is needed is unclear, the plugin documentation doesn't explain it.

          This does not appear to be a vulnerability unless passwords are stored in plain text or otherwise handled unsafely. That an org's requirements are incompatible, or a use case is unsupported, does not make this a vulnerability.

          In case the plugin authors change this, care needs to be taken to integrate with Credentials plugin,rather than require passwords to be entered ad-hoc in job configurations. The latter can easily result in problems and does not work well with Pipeline. Another option would be to allow defining folder-level (as FolderProperty) endpoints/credentials to limit their Jenkins-wide exposure.

          Daniel Beck added a comment - - edited kon Thanks for the ping. While I don't understand exactly how this plugin works, many plugins set up "remote endpoints" of some sort with globally defined credentials for them to be referenced in jobs. That said, I would expect a dedicated "Jenkins user" to be specified to interact with HP ALM from Jenkins, but perhaps that's not possible? I tried the plugin and it's possible to specify multiple servers, each with multiple usernames/passwords. Why that is needed is unclear, the plugin documentation doesn't explain it. This does not appear to be a vulnerability unless passwords are stored in plain text or otherwise handled unsafely. That an org's requirements are incompatible, or a use case is unsupported, does not make this a vulnerability. In case the plugin authors change this, care needs to be taken to integrate with Credentials plugin,rather than require passwords to be entered ad-hoc in job configurations. The latter can easily result in problems and does not work well with Pipeline. Another option would be to allow defining folder-level (as FolderProperty) endpoints/credentials to limit their Jenkins-wide exposure.

          Amit Dar added a comment -

          I just want to make sure I was clear:

          the security breach is NOT in Jenkins... it is in Quality Center.

          I mean that this issue causes a user of quality center to gain control and use credentials he or she do not have, and use them on quality center without permission or knowledge from their real owners.

          Amit Dar added a comment - I just want to make sure I was clear: the security breach is NOT in Jenkins... it is in Quality Center. I mean that this issue causes a user of quality center to gain control and use credentials he or she do not have, and use them on quality center without permission or knowledge from their real owners.

          Hilda added a comment -

          Hello,

          Jenkins MF Plugin version 7.1 was officially released. 

          In this release was introduced the Job level and Global level credential handling.

           

          Thank you,

          Hilda

          Hilda added a comment - Hello, Jenkins MF Plugin version 7.1 was officially released.  In this release was introduced the Job level and Global level credential handling.   Thank you, Hilda

            dbogdan7 Dorin Bogdan
            amidar Amit Dar
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: