Since revision 7493, I believe there is an information leak possible in hsm_get_key_ecdsa_value, in libhsm.c. Uninitialized memory can be copied as part of the returned data (Q).
This information leak might occur when the HSM cannot be trusted (e.g. network HSM with flawed communication protocol or smartcards), and even with a well-behaving PKCS#11 module.
Two calls are performed to C_GetAttributeValue.
The first is made to get the size of the memory to allocate on the heap. This memory, once allocated, is not initialized.
The second call is made to copy the CKA_EC_POINT into the allocated memory. The allocated memory size is provided as parameter to prevent the PKCS#11 module from overflowing the memory.
There is however no check on whether the second call actually writes the whole allocated memory.
An adversarial HSM could return a large size on the first call, thus allocating a large quantity of memory and then provide a very small value on the second call, thus overwriting only a small fraction of the allocated memory.
The quantity of memory actually written during the second call is never checked nor used.
At the end of the function, a memcpy call is performed with the *data_len size, calculated with value_len. value_len is the size of the allocated memory and not the size of the written memory.
This results in having the returned data chunk containing uninitialized memory potentially containing sensitive information. If this memory chunk is later displayed to the adversary, for instance in a DNSKEY resource record, sensitive information could be disclosed.
There are multiple ways to fix this issue.
One could :
- initialize the allocated memory to ensure no sensitive data is available
- the actual *data_len size could be computed with template.ulValueLen (resulting from the second call of C_GetAttributeValue) instead of value_len
- check whether the two C_GetAttributeValue calls result in the ulValueLen value. This fix could help detect adversarial or buggy HSM.