libspdm is a sample implementation that follows the DMTF SPDM specifications. In version 1.4.0, both the FINISH request (Table 80) and the FINISHRSP response (Table 81) gained two new fields, OpaqueDataLength and OpaqueData, placed before the trailing signed/authenticated field. The transcript definitions used to compute and verify the FINISH signature, the FINISH HMAC (RequesterVerifyData), and the FINISHRSP HMAC (ResponderVerifyData) were not updated and still terminate with a step of the form. Per DSP0274, the "SPDM Header Fields" are only the four header bytes (SPDMVersion, RequestResponseCode, Param1, Param2). A literal reading therefore excludes OpaqueDataLength and OpaqueData, even though those fields are transmitted before the trailing signature/HMAC field. Because the signature/HMAC must cover every field transmitted before it to "protect the entire handshake against manipulation by an active attacker," an active attacker could otherwise modify the opaque data in flight without invalidating the signature or HMAC. This issue has been patched in version 1.4.1.

libspdm is a sample implementation that follows the DMTF SPDM specifications. A vulnerability has been identified in SPDM session establishment in libspdm prior to version 2.3.1. If a device supports both DHE session and PSK session with mutual authentication, the attacker may be able to establish the session with KEYEXCHANGE and PSKFINISH to bypass the mutual authentication. This is most likely to happen when the Requester begins a session using one method (DHE, for example) and then uses the other method's finish (PSKFINISH in this example) to establish the session. The session hashes would be expected to fail in this case, but the condition was not detected.

This issue only impacts the SPDM responder, which supports KEYEXCAP=1 and PSKCAP=10b at same time with mutual authentication requirement. The SPDM requester is not impacted. The SPDM responder is not impacted if KEYEXCAP=0 or PSKCAP=0 or PSKCAP=01b. The SPDM responder is not impacted if mutual authentication is not required.

libspdm 1.0, 2.0, 2.1, 2.2, 2.3 are all impacted. Older branches are not maintained, but users of the 2.3 branch may receive a patch in version 2.3.2. The SPDM specification (DSP0274) does not contain this vulnerability.

libspdm is a sample implementation that follows the DMTF SPDM specifications. Prior to versions 2.3.3 and 3.0, following a successful CAPABILITIES response, a libspdm Requester stores the Responder's CTExponent into its context without validation. If the Requester sends a request message that requires a cryptography operation by the Responder, such as CHALLENGE, libspdm will calculate the timeout value using the Responder's unvalidated CTExponent.

A patch is available in version 2.3.3. A workaround is also available. After completion of VCA, the Requester can check the value of the Responder's CTExponent. If it greater than or equal to 64, then the Requester can stop communication with the Responder.