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: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | 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
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). Lifting embargo. 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. |