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

Potential LDAP injection bug

    XMLWordPrintable

Details

    Description

      In: ActiveDirectoryUnixAuthenticationProvider.java

      Line 85:
      context.search(toDC(domainName),"(&
      (userPrincipalName="principalName")(objectClass=user))", controls);

      Line 89:
      renum = context.search(toDC(domainName),"(&
      (sAMAccountName="username")(objectClass=user))", controls);

      String appends with no escaping leave the code vulnerable to an (unlikely) LDAP
      injection attack.

      The Acegi code already has protection against this, you can see how that's
      implemented here:
      https://src.springframework.org/svn/spring-security/tags/release_1_0_6/core/src/main/java/org/acegisecurity/ldap/search/FilterBasedLdapUserSearch.java

      (this eventually ends up using the spring code for encoding, in
      org/springframework/ldap/support/LdapEncoder.java)

      If you use the LdapTemplate code to do this, as acegi did, see the notes about
      referrals at:
      http://static.springframework.org/spring-ldap/docs/1.1/api/org/springframework/ldap/LdapTemplate.html

      Incidentally, this referrals stuff should be irrelevant for authentication; if
      you connect to the Global Catalog Server (port 3268) for your forest, not the AD
      server (port 389), you should not be seeing referrals. Hudson is querying
      _ldap._tcp.<domain name>, but should probably be querying
      _gc._tcp.<DnsForestName>. (equivalent, I think, to COM4J.getObject(IADs.class,
      "GC:", null); in the windows version, instead of COM4J.getObject(IADs.class,
      "LDAP://RootDSE", null)

      Attachments

        Activity

          People

            Unassigned Unassigned
            bazzargh bazzargh
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: