Important: Red Hat Certificate System security and bug fix update

Important: Red Hat Certificate System 10.4 for RHEL 8 security and bug fix update

A flaw was found in pki-core, which could allow a user to get a certificate for another user identity when directory-based authentication is enabled. This flaw allows an authenticated attacker on the adjacent network to impersonate another user within the scope of the domain, but they would not be able to decrypt message content.

A flaw was found in pki-core. An attacker who has successfully compromised a key could use this flaw to renew the corresponding certificate over and over again, as long as it is not explicitly revoked. The highest threat from this vulnerability is to data confidentiality and integrity.

Files are accessible without restrictions from the /update/results page of redhat-certification package, allowing an attacker to remove any file accessible by the apached user.

Format string vulnerability in the token processing system (pki-tps) in Red Hat Certificate System (RHCS) 8.1 and possibly Dogtag Certificate System 9 and 10 allows remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via format string specifiers in unspecified vectors, related to viewing certificates.

It was reported that Certificate System suffers from XSS flaws in the /tus/ and /tus/tus/ URLs, such as:

GET /tus/tus/%22%2b%61%6c%65%72%74%28%34%38%32%36%37%29%2b%22

or

GET /tus/%22%2b%61%6c%65%72%74%28%36%31%34%35%32%29%2b%22

which will in turn output something like:

<!-- var uriBase = "/tus/"+alert(85384)+"; var userid = "admin";

This was reported against Certificate System 8.1 and may also affect Dogtag 9 and 10.

It was discovered that the Red Hat Certificate System's / Dogtag Certificate System's Certificate Manager did not properly check certificate revocation requests. An agent permitted to perform revocations of end entity certificates via Certificate System's web interface could use this flaw to revoke the Certificate Authority (CA) certificate.

The issue was originally reported via bug #832212.

Patch applied to address this issue: https://fedorahosted.org/pki/changeset/2430

Red Hat / Dogtag Certificate System did not prevent re-use of the one-time PIN used in the SCEP (Simple Certificate Enrollment Protocol) protocol enrollment requests. The check was done to ensure that PIN is valid, but the PIN was never removed from the list of valid PINs once it was used. An attacker possessing a valid SCEP enrollment one-time PIN could use it to generate an unlimited number of certificates.

Red Hat / Dogtag Certificate System did not prevent re-use of the one-time PIN used in the SCEP (Simple Certificate Enrollment Protocol) protocol enrollment requests. The check was done to ensure that PIN is valid, but the PIN was never removed from the list of valid PINs once it was used. An attacker possessing a valid SCEP enrollment one-time PIN could use it to generate an unlimited number of certificates.

Red Hat / Dogtag Certificate System's Certificate Authority can be asked to decrypt one-time PIN used in the SCEP (Simple Certificate Enrollment Protocol) protocol requests. This feature is intended to be used by Registration Authorities that act as proxies between CA users (e.g. network devices enrolling using SCEP protocol) and CA itself. However, Red Hat Certificate System lacked proper authentication mechanisms to ensure such decryption requests are only replied if sent form the configured Registration Authority. An attacker able to sniff SCEP request of the network could use this flaw to request decryption of the sniffed request and obtain one-time PIN.

Red Hat Certificate System updates add proper authentication, only configured authenticated Registration Authorities can request SCEP one-time PIN decryption.

Red Hat / Dogtag Certificate System's Certificate Authority can be asked to decrypt one-time PIN used in the SCEP (Simple Certificate Enrollment Protocol) protocol requests. This feature is intended to be used by Registration Authorities that act as proxies between CA users (e.g. network devices enrolling using SCEP protocol) and CA itself. However, Red Hat Certificate System lacked proper authentication mechanisms to ensure such decryption requests are only replied if sent form the configured Registration Authority. An attacker able to sniff SCEP request of the network could use this flaw to request decryption of the sniffed request and obtain one-time PIN.

Red Hat Certificate System updates add proper authentication, only configured authenticated Registration Authorities can request SCEP one-time PIN decryption.

Robert Mead reported that the Registration Authority component (rhpki-ra) of the Red Hat Certificate System / Dogtag Certificate System did not properly check agent's authorizations in some CGI scripts.

In deployments, where certificate requests are processed by multiple agent groups, agent from any group was able to approve or reject certificate requests in the queue for any other agent group, if he was able to guess request ID.

Original report: bug #484828

Affected systems: Dogtag Certificate System Red Hat Certificate System 7.3

During the internal code review, it was discovered that Red Hat Certificate System / Dogtag Certificate System does not properly verify challenge response received during the enrollment of new security token.

If keys are generated on the token during the enrollment, TPS correctly verifies that the requestor possesses the private key, but fails to verify that the key really exists on the token and is not only in software.

An attacker with access to blank token known to TPS component and with privilege to perform enrollments of new tokens could use this flaw to successfully finish enrollment procedure with the software generated key instead of the one stored in the token.

Affected versions: Red Hat Certificate System 7.1, 7.2, 7.3 Dogtag Certificate System 1.0

During the internal code review, it was discovered that Red Hat Certificate System / Dogtag Certificate System does not properly verify challenge response received during the enrollment of new security token.

If keys are generated on the token during the enrollment, TPS correctly verifies that the requestor possesses the private key, but fails to verify that the key really exists on the token and is not only in software.

An attacker with access to blank token known to TPS component and with privilege to perform enrollments of new tokens could use this flaw to successfully finish enrollment procedure with the software generated key instead of the one stored in the token.

Affected versions: Red Hat Certificate System 7.1, 7.2, 7.3 Dogtag Certificate System 1.0

It was discovered that Red Hat Certificate System may store plain text passwords in multiple debug log files (such as UserDirEnrollment password or RA wizard installer log).

This problem allows any local user to extract plain text passwords from the Red Hat Certificate System debug log files.

It was discovered that Red Hat Certificate System use insecure default file permissions on configuration files (such as password.conf) that may contain authentication credentials or other sensitive information that should only be accessible to administrative and service users.

This problem allows any local user to read Red Hat Certificate System configuration files.

A flaw was found in a way Red Hat Certificate System handled Extensions in the certificate signing requests (CSR). All requested Extensions were added to issued certificate despite constraints defined in Certificate Authority (CA) profile.

For example, CSR could contain Basic Constraints or Key Usage constraint that once copied to issued certificate would result in creation of subordinate CA certificate, even though CA configuration prohibits issuing of subordinate CA certificate, possibly leading to a bypass the intended security policy.

Affected versions: Red Hat Certificate System 7.1, 7.2, 7.3 Netscape Certificate Management System 6.x

A flaw was found in a way Red Hat Certificate System handled Extensions in the certificate signing requests (CSR). All requested Extensions were added to issued certificate despite constraints defined in Certificate Authority (CA) profile.

For example, CSR could contain Basic Constraints or Key Usage constraint that once copied to issued certificate would result in creation of subordinate CA certificate, even though CA configuration prohibits issuing of subordinate CA certificate, possibly leading to a bypass the intended security policy.

Affected versions: Red Hat Certificate System 7.1, 7.2, 7.3 Netscape Certificate Management System 6.x