An issue was discovered in Yubico libykpiv before 2.1.0. lib/util.c in this library (which is included in yubico-piv-tool) does not properly check embedded length fields during device communication. A malicious PIV token can misreport the returned length fields during RSA key generation. This will cause stack memory to be copied into heap allocated memory that gets returned to the caller. The leaked memory could include PINs, passwords, key material, and other sensitive information depending on the integration. During further processing by the caller, this information could leak across trust boundaries. Note that RSA key generation is triggered by the host and cannot directly be triggered by the token.

An issue was discovered in Yubico libykpiv before 2.1.0. An attacker can trigger an incorrect free() in the ykpiv_util_generate_key() function in lib/util.c through incorrect error handling code. This could be used to cause a denial of service attack.

VMware Workspace ONE SDK and dependent mobile application updates address sensitive information disclosure vulnerability.

An out-of-bounds read issue was discovered in the Yubico-Piv 1.5.0 smartcard driver. The file lib/ykpiv.c contains the following code in the function `_ykpiv_fetch_object()`: {% highlight c %} if(sw == SW_SUCCESS) { size_t outlen; int offs = _ykpiv_get_length(data + 1, &outlen); if(offs == 0) { return YKPIV_SIZE_ERROR; } memmove(data, data + 1 + offs, outlen); *len = outlen; return YKPIV_OK; } else { return YKPIV_GENERIC_ERROR; } {% endhighlight %} -- in the end, a `memmove()` occurs with a length retrieved from APDU data. This length is not checked for whether it is outside of the APDU data retrieved. Therefore the `memmove()` could copy bytes behind the allocated data buffer into this buffer.

A buffer overflow issue was discovered in the Yubico-Piv 1.5.0 smartcard driver. The file lib/ykpiv.c contains the following code in the function `ykpiv_transfer_data()`: {% highlight c %} if(*out_len + recv_len - 2 > max_out) { fprintf(stderr, "Output buffer to small, wanted to write %lu, max was %lu.", *out_len + recv_len - 2, max_out); } if(out_data) { memcpy(out_data, data, recv_len - 2); out_data += recv_len - 2; *out_len += recv_len - 2; } {% endhighlight %} -- it is clearly checked whether the buffer is big enough to hold the data copied using `memcpy()`, but no error handling happens to avoid the `memcpy()` in such cases. This code path can be triggered with malicious data coming from a smartcard.