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.

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.

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...

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.

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.