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

SECURITY: LDAP authenticated users switch accounts randomly

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: _unsorted
    • Labels:
      None
    • Environment:
    • Similar Issues:

      Description

      Running Jenkins behind Apache: mod_proxy with HTTPS
      https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache
      So our setup is
      Open Directory group
      jenkins-admin - Jenkins Admins all
      dev-group-a - Developers can view kick off builds

      Project-based Matrix Authorization Strategy
      Admin all checked
      dev-group-a checked: Overall:Read Job:Read,Build Run:Update
      dev-group-b checked: Overall:Read Job:Read

      issue is I'm an admin and random developer will login and see that there user id is mine and can admin jenkins.

      there has been reported cases that developer A will login and actually be reported by jenkins as Developer B
      were they can no longer trigger CI builds

      My biggest concern is when users login and are reporting as admins and have full access to jenkins.

        Attachments

          Activity

          Hide
          dogfood dogfood added a comment -

          Integrated in jenkins_ui-changes_branch #30
          [FIXED JENKINS-12585] restrict where sessions are created. (Revision 7a4858d65f2431396c2f4dadbc3d654712bc02a8)

          Result = SUCCESS
          Kohsuke Kawaguchi : 7a4858d65f2431396c2f4dadbc3d654712bc02a8
          Files :

          • changelog.html
          • core/src/main/java/hudson/security/AuthenticationProcessingFilter2.java
          • core/src/main/resources/lib/layout/layout.jelly
          • war/src/main/webapp/WEB-INF/security/SecurityFilters.groovy
          Show
          dogfood dogfood added a comment - Integrated in jenkins_ui-changes_branch #30 [FIXED JENKINS-12585] restrict where sessions are created. (Revision 7a4858d65f2431396c2f4dadbc3d654712bc02a8) Result = SUCCESS Kohsuke Kawaguchi : 7a4858d65f2431396c2f4dadbc3d654712bc02a8 Files : changelog.html core/src/main/java/hudson/security/AuthenticationProcessingFilter2.java core/src/main/resources/lib/layout/layout.jelly war/src/main/webapp/WEB-INF/security/SecurityFilters.groovy
          Hide
          dogfood dogfood added a comment -

          Integrated in jenkins_main_trunk #1701
          [FIXED JENKINS-12585] restrict where sessions are created. (Revision 7a4858d65f2431396c2f4dadbc3d654712bc02a8)

          Result = UNSTABLE
          Kohsuke Kawaguchi : 7a4858d65f2431396c2f4dadbc3d654712bc02a8
          Files :

          • war/src/main/webapp/WEB-INF/security/SecurityFilters.groovy
          • core/src/main/resources/lib/layout/layout.jelly
          • changelog.html
          • core/src/main/java/hudson/security/AuthenticationProcessingFilter2.java
          Show
          dogfood dogfood added a comment - Integrated in jenkins_main_trunk #1701 [FIXED JENKINS-12585] restrict where sessions are created. (Revision 7a4858d65f2431396c2f4dadbc3d654712bc02a8) Result = UNSTABLE Kohsuke Kawaguchi : 7a4858d65f2431396c2f4dadbc3d654712bc02a8 Files : war/src/main/webapp/WEB-INF/security/SecurityFilters.groovy core/src/main/resources/lib/layout/layout.jelly changelog.html core/src/main/java/hudson/security/AuthenticationProcessingFilter2.java
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          core/src/main/java/hudson/security/AuthenticationProcessingFilter2.java
          core/src/main/resources/lib/layout/layout.jelly
          war/src/main/webapp/WEB-INF/security/SecurityFilters.groovy
          http://jenkins-ci.org/commit/jenkins/7a4858d65f2431396c2f4dadbc3d654712bc02a8
          Log:
          [FIXED JENKINS-12585] restrict where sessions are created.

          If a resource with 'Set-Cookie' header is cached (either by intermediary
          like HTTP proxy and reverse proxy, or by the browser), it'll cause
          identity swap / session mix-up as discussed in this ticket.

          I suspect this was caused by HttpSessionContextIntegrationFilter2, which
          is the only code path that attempts to create a session when a request
          to a static resource is made.

          So I'm disabling the creation of session in
          HttpSessionContextIntegrationFilter2. This in turn requires that we
          have sessions already created when the authentication was successful and
          people need to login (or else the login will have no effect.)

          We already do so in layout.jelly, so any request that renders a Jenkins
          page would have a session, but I've also added it in
          AuthenticationProcessingFilter2, which ensures that a successful login
          does have a session.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/src/main/java/hudson/security/AuthenticationProcessingFilter2.java core/src/main/resources/lib/layout/layout.jelly war/src/main/webapp/WEB-INF/security/SecurityFilters.groovy http://jenkins-ci.org/commit/jenkins/7a4858d65f2431396c2f4dadbc3d654712bc02a8 Log: [FIXED JENKINS-12585] restrict where sessions are created. If a resource with 'Set-Cookie' header is cached (either by intermediary like HTTP proxy and reverse proxy, or by the browser), it'll cause identity swap / session mix-up as discussed in this ticket. I suspect this was caused by HttpSessionContextIntegrationFilter2, which is the only code path that attempts to create a session when a request to a static resource is made. So I'm disabling the creation of session in HttpSessionContextIntegrationFilter2. This in turn requires that we have sessions already created when the authentication was successful and people need to login (or else the login will have no effect.) We already do so in layout.jelly, so any request that renders a Jenkins page would have a session, but I've also added it in AuthenticationProcessingFilter2, which ensures that a successful login does have a session.
          Hide
          alexlehm Alex Lehmann added a comment -

          I forgot to mention yesterday, I compared one jenkins instance with logged-in access only to one that has anonymous, both set a cookie on the start page, the logged-in instance has 403 and no no-cache header, the anonymous instance has Cache-Control: no-cache,must-revalidate.

          Both looks correct and the static files do not send a set-cookie header.

          Show
          alexlehm Alex Lehmann added a comment - I forgot to mention yesterday, I compared one jenkins instance with logged-in access only to one that has anonymous, both set a cookie on the start page, the logged-in instance has 403 and no no-cache header, the anonymous instance has Cache-Control: no-cache,must-revalidate. Both looks correct and the static files do not send a set-cookie header.
          Hide
          docwhat Christian Höltje added a comment -

          Just a clarification. It doesn't have to be a static asset.

          Tomcat could have (according to the brief description on some stackoverflow article I can't find now) sent it on any page. It doesn't send JSESSIONID on every URL requested, but has some logic for when to do it.

          The only thing needed to poison apache's cache would be that:

          a) A page that is cacheable. This isn't always just pages with an "Expires" or "Last-Modified" header. The rules are... a little esoteric at times, and who knows how apache interprets them.
          b) A page that sent the Set-Cookie header.

          Also, as you mentioned in IRC, there is no point trying to "recover" a poisoned cache. Your only real choice is to turn off the proxy-cache, or reset it with either a fix (like CacheIgnoreHeader Set-Cache) or the new as-yet-unwritten Jenkins.

          Show
          docwhat Christian Höltje added a comment - Just a clarification. It doesn't have to be a static asset. Tomcat could have (according to the brief description on some stackoverflow article I can't find now) sent it on any page. It doesn't send JSESSIONID on every URL requested, but has some logic for when to do it. The only thing needed to poison apache's cache would be that: a) A page that is cacheable. This isn't always just pages with an "Expires" or "Last-Modified" header. The rules are... a little esoteric at times, and who knows how apache interprets them. b) A page that sent the Set-Cookie header. Also, as you mentioned in IRC, there is no point trying to "recover" a poisoned cache. Your only real choice is to turn off the proxy-cache, or reset it with either a fix (like CacheIgnoreHeader Set-Cache) or the new as-yet-unwritten Jenkins.

            People

            • Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              geevez guillermo c
            • Votes:
              10 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: