Bug 475998 (CVE-2008-5082) - CVE-2008-5082 Certificate System: missing public key challenge proof verification in the TPS component
Summary: CVE-2008-5082 Certificate System: missing public key challenge proof verifica...
Alias: CVE-2008-5082
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 473171
TreeView+ depends on / blocked
Reported: 2008-12-11 14:28 UTC by Tomas Hoger
Modified: 2019-09-29 12:28 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-29 09:58:56 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:0007 normal SHIPPED_LIVE Moderate: rhpki security and bug fix update 2009-01-29 09:31:12 UTC

Description Tomas Hoger 2008-12-11 14:28:53 UTC
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

Comment 1 Tomas Hoger 2008-12-11 14:41:00 UTC
Further details from Christina Fu and Bob Relyea:

This issue affects only enrollments involving keys generated on the tokens.  When keys are generated on the tokens, TPS has the responsibility to make sure that the following 2 conditions are met:
a. The caller indeed possesses the private key
b. The private key indeed exists on the token

To guarantee both conditions, a random 16 byte data (challenge) is generated on the server side encrypted with a shared secret (Key Encryption Key) between the token and the server.  The token, upon receiving the encrypted data, decrypts the data with the same secret known to only the token and the server, and signs the data with it's private key and sends the signed data along with it's public key to the server for enrollment.

When the server (TPS) receives this enrollment request, it calls the verifyProof() function, which verifies the signature of the signed data against the challenge.  The (a bit simplified) description of the process tells us that:

1. The fact that the token is able to decrypt the challenge proves that the server is talking to a known token.
2. The fact that the signed challenge verifies proves that the caller indeed possesses the private key matching the public key submitted for enrollment.

This flaw is within the verifyProof() function itself.  In case of some failures, it sets the ReturnValue's statusNum, but forgets to set its status to PR_FAILURE.  As a result, it always returns success (the default).

This flaw potentially downgrades what hardware token can provide for you to the security grade level of a software token.

Real effect of the flaw depends on the way TPS is used in specific deployment.  It can be used in the officer mode, when only privileged (and trusted) security officer is allowed to enroll new tokens.  This issue may have greater impact in deployments where individual users are allowed to enroll their tokens via ESC (Enterprise Security Client).

Comment 2 Tomas Hoger 2009-01-29 09:29:02 UTC
Lifting embargo.

Comment 3 Red Hat Product Security 2009-01-29 09:58:56 UTC
This issue was addressed in:

Red Hat Certificate System:

Note: It is currently not planned to address this issue in Red Hat Certificate
System 7.1 and 7.2.

Note You need to log in before you can comment on or make changes to this bug.