The REST interface definition specifies a list of parameters that it will use to construct a search filter. However, currently it's possible to inject filter fragments that will alter the final filter beyond its original intention.

For example, the service at /kra/pki/keyrequests are supposed to take request state, request type and client ID only. The service will concatenate the parameter values into a filter string like this:

(&(requestState=)(requestType=)(clientID=))

The filter string will be parsed by DBRegistry.getFilter() and the parameter names will be translated by the LdapFilterConverter.convert() into internal LDAP attributes. Any of the following parameter names are acceptable:

• certRecordId
• certMetaInfo
• certRevoInfo
• certStatus
• certCreateTime
• certModifyTime
• certAutoRenew
• certIssuedBy
• certRevokedBy
• certRevokedOn
• x509cert
• notBefore
• notAfter
• id
• crlNumber
• deltaNumber
• crlSize
• deltaSize
• thisUpdate
• nextUpdate
• firstUnsaved
• certificaterevocationlist
• crlCache
• cACertificate
• revokedCerts
• unrevokedCerts
• expiredCerts
• deltaRevocationList
• keySerialNumber
• keyState
• algorithm
• keySize
• keyOwnerName
• privateKey
• publicKey
• dateOfRecovery
• keyCreateTime
• keyModifyTime
• keyMetaInfo
• keyArchivedBy
• clientId
• dataType
• status

Since the parameter values are concatenated, it's possible to inject filter fragments that include additional parameter names from the above list.

For example, the certModifyTime is not in the parameter list of /kra/pki/keyrequests, but it can be injected as follows:

• requestState: *
• requestType: *)(certModifyTime>=20120301000000Z

In the URL the above parameters will look like this:

requestState=&requestType=)(certModifyTime>%3d20120301000000Z

It will generate the following LDAP filter:

(&(requestState=)(requestType=)(dateOfModify>=20120301000000Z))

Whether this can be exploited to gain privileged information depends on some other factors. In this particular case since the outermost operator is an AND, any additional attributes will only narrow down the search results. However, an attacker might be able to use it to confirm the value of an attribute that's not supposed to be visible. If the outermost operator is an OR, the attacker might be able to widen the search results.

Another example, the /kra/pki/keys is supposed to take status and client ID parameters only, but privateKey can be injected into the parameters:

- status: *
- clientID: *)(privateKey=\12\34\56\78

In the URL the above parameters will look like this:

/kra/pki/keys?status=&clientID=)(privateKey%3d%5c12%5c34%5c56%5c78

It will generate the following LDAP filter:

(&(status=)(clientId=)(privateKeyData=\12\34\56\78))

Note, the privateKeyData is not searchable probably due to the schema configuration, but this example shows the vulnerability.

This is fixed in ticket #96.

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/664

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.