See how libtpms project compares to other vendors in security performance
libtpms, a library that provides software emulation of a Trusted Platform Module, has a flaw in versions 0.10.0 and 0.10.1. The commonly used integration of libtpms with OpenSSL 3.x contained a vulnerability related to the returned IV (initialization vector) when certain symmetric ciphers were used. Instead of returning the last IV it returned the initial IV to the caller, thus weakening the subsequent encryption and decryption steps. The highest threat from this vulnerability is to data confidentiality. Version 0.10.2 fixes the issue. No known workarounds are available.
Libtpms is a library that targets the integration of TPM functionality into hypervisors, primarily into Qemu. Libtpms, which is derived from the TPM 2.0 reference implementation code published by the Trusted Computing Group, is prone to a potential out of bounds (OOB) read vulnerability. The vulnerability occurs in the ‘CryptHmacSign’ function with an inconsistent pairing of the signKey and signScheme parameters, where the signKey is ALGKEYEDHASH key and inScheme is an ECC or RSA scheme. The reported vulnerability is in the ‘CryptHmacSign’ function, which is defined in the "Part 4: Supporting Routines – Code" document, section "7.151 - /tpm/src/crypt/CryptUtil.c ". This vulnerability can be triggered from user-mode applications by sending malicious commands to a TPM 2.0/vTPM (swtpm) whose firmware is based on an affected TCG reference implementation. The effect on libtpms is that it will cause an abort due to the detection of the out-of-bounds access, thus for example making a vTPM (swtpm) unavailable to a VM. This vulnerability is fixed in 0.7.12, 0.8.10, 0.9.7, and 0.10.1.
A bug was discovered in the libtpms code that may cause access beyond the boundary of internal buffers. The vulnerability can be triggered by specially-crafted TPM 2 command packets that then trigger the issue when the state of the TPM 2's volatile state is marshalled/written.
Reference and upstream patches: https://github.com/stefanberger/libtpms/commit/1fb6cd9b8df05b5d6e381b31215193d6ada969df https://github.com/stefanberger/libtpms/commit/ea62fd9679f8c6fc5e79471b33cfbd8227bfed72
A bug was discovered in the libtpms code that may cause access to a buffer beyond the boundary of the buffer or cause failures when trying to resume the state of the vTPM. The vulnerability can be triggered by specially-crafted TPM 2 command packets containing unacceptable/illegal values and those values become an issue when the volatile state of the TPM 2 is marshalled/written or unmarshalled/read. In the former case this can lead to a buffer access beyond its boundary and in the latter case to refusal to accept the state blob due to an illegal value.
To the best of our knowledge, the buffer access beyond its boundaries case does NOT lead to code execution, and as such, any exploitation is likely limited to information leakage and / or denial-of-service (DoS), i.e. a crash. Further, an attacker must have (indirect or direct) access to call TPMLIBVolatileAllStore to exploit this flaw.
Upstream PR: https://github.com/stefanberger/libtpms/pull/223
Upstream fix: https://github.com/stefanberger/libtpms/commit/2f30d62 https://github.com/stefanberger/libtpms/commit/7981d9a https://github.com/stefanberger/libtpms/commit/2e6173c
A stack corruption bug was found in libtpms in versions before 0.7.2 and before 0.8.0 while decrypting data using RSA. This flaw could result in a SIGBUS (bad memory access) and termination of swtpm. The highest threat from this vulnerability is to system availability.
A flaw was found in libtpms in versions before 0.8.0. The TPM 2 implementation returns 2048 bit keys with ~1984 bit strength due to a bug in the TCG specification. The bug is in the key creation algorithm in RsaAdjustPrimeCandidate(), which is called before the prime number check. The highest threat from this vulnerability is to data confidentiality.
A flaw was found in libtpms in versions before 0.8.2. The commonly used integration of libtpms with OpenSSL contained a vulnerability related to the returned IV (initialization vector) when certain symmetric ciphers were used. Instead of returning the last IV it returned the initial IV to the caller, thus weakening the subsequent encryption and decryption steps. The highest threat from this vulnerability is to data confidentiality.