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

EnvInject exposes password hashes

    XMLWordPrintable

Details

    Description

      Currently, if a user without configuration access to a job can read the job they have access to the link "Environment variables". This allows the non-privileged user to see the password hashes.

      If they have Config access to a different folder on the same master, they can use this password hash to expose the password and take control of the account by using the CLI to directly change the job config.xml

      I propose that this link or at least the password hashes be restricted to only users with job config access.

      Attachments

        Issue Links

          Activity

            jglick Jesse Glick added a comment -

            Not sure what “password hash” means in this context but is this just a duplicate of JENKINS-23447?

            jglick Jesse Glick added a comment - Not sure what “password hash” means in this context but is this just a duplicate of JENKINS-23447 ?
            danielbeck Daniel Beck added a comment -

            jglick: No, this is about variables recognized by Env-Inject as passwords. They're only shown in encrypted form on the Injected Env Vars page, but that can be reused in another job in the same instance the malicious user has config access to: Just run env there and you "decrypted" the password.

            danielbeck Daniel Beck added a comment - jglick : No, this is about variables recognized by Env-Inject as passwords. They're only shown in encrypted form on the Injected Env Vars page, but that can be reused in another job in the same instance the malicious user has config access to: Just run env there and you "decrypted" the password.
            elliottjones Elliott Jones added a comment -

            Any thoughts on this being fixed? We have to use passwords managed by a separate IT team for our CI process thus this issue is of concern to them.

            elliottjones Elliott Jones added a comment - Any thoughts on this being fixed? We have to use passwords managed by a separate IT team for our CI process thus this issue is of concern to them.
            oleg_nenashev Oleg Nenashev added a comment -

            JENKINS-29867 (https://github.com/jenkinsci/envinject-plugin/pull/57) should partially address this use-case in 1.92+

            oleg_nenashev Oleg Nenashev added a comment - JENKINS-29867 ( https://github.com/jenkinsci/envinject-plugin/pull/57 ) should partially address this use-case in 1.92+
            oleg_nenashev Oleg Nenashev added a comment -

            I think the JENKINS-29867 fix is enough. Please reopen the issue if you expect something else to be delivered

            oleg_nenashev Oleg Nenashev added a comment - I think the JENKINS-29867 fix is enough. Please reopen the issue if you expect something else to be delivered

            People

              oleg_nenashev Oleg Nenashev
              walterk82 Walter Kacynski
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: