Bug 475998 (CVE-2008-5082)

Summary: CVE-2008-5082 Certificate System: missing public key challenge proof verification in the TPS component
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: cfu, ckannan, kevinu, kwirth, mharmsen, rrelyea, shaines
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-29 09:58:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 473171    
Bug Blocks:    

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:
  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.