Bug 475998 - (CVE-2008-5082) CVE-2008-5082 Certificate System: missing public key challenge proof verification in the TPS component
CVE-2008-5082 Certificate System: missing public key challenge proof verifica...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
source=redhat,reported=20081126,publi...
: Security
Depends On: 473171
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-11 09:28 EST by Tomas Hoger
Modified: 2009-01-29 04:58 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-29 04:58:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-12-11 09:28:53 EST
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 09:41:00 EST
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 04:29:02 EST
Lifting embargo.
Comment 3 Red Hat Product Security 2009-01-29 04:58:56 EST
This issue was addressed in:

Red Hat Certificate System:
  http://rhn.redhat.com/errata/RHSA-2009-0007.html

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.