Microchip cryptoauthlib atcab_sign_base buffer overflow
| CENSUS ID: | CENSUS-2020-0003 |
| CVE ID: | CVE-2019-16128 |
| Affected Products: | cryptoauthlib versions prior to "20191122" |
| Class: | Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')(CWE-120) |
| Discovered by: | George Poulios |
CENSUS identified a buffer overflow vulnerability in the atcab_sign_base function of the cryptoauthlib library. This library is part of the standard SDK provided by Microchip and is used to drive the operation of cryptographic co-processors sold by the vendor, such as the ATECC608A. An attacker with physical access to an embedded device where a microcontroller unit executes a vulnerable version of this library, may be able to execute arbitrary code on the microcontroller, by supplying malicious input to the microcontroller. Affected manufacturers of embedded systems that use Microchip cryptographic co-processors, are strongly recommended to update to at least version "20191122" of the "cryptoauthlib" library.
Vulnerability Details
During the security assessment of an embedded device bearing the Microchip ATSAMD51J20A microcontroller unit and the Microchip ATECC608A cryptographic co-processor, CENSUS identified that the microcontroller firmware was vulnerable to a buffer overflow attack.
Specifically, the firmware of the microcontroller unit used the cryptoauthlib library function atcab_sign_base within the context of a signing operation involving the cryptographic co-processor. The "cryptoauthlib" library is part of the Microchip SDK and is the standard mechanism by which one drives the operation of cryptographic co-processors of Microchip.
CENSUS spotted an inconsistency between the documentation and the implementation of atcab_sign_base (see cryptoauthlib/lib/basic/atca_basic_sign.c). The function will call at_sign and atca_execute_command to perform a signing operation using the cryptographic co-processor. The result of the signing operation will then be transferred to the "signature" buffer by means of a call to memcpy.
Although the documentation states that the buffer for the returned signature should be 64 bytes, in line 78 the size of the memcpy operation is determined by the received packet. This packet is expected to come from the cryptographic co-processor however, an attacker with physical access to the device can inject such a packet with contents of their choosing on the bus.
ATCA_STATUS atcab_sign_base(uint8_t mode, uint16_t key_id, uint8_t *signature)
{
ATCAPacket packet;
ATCACommand ca_cmd = _gDevice->mCommands;
ATCA_STATUS status = ATCA_GEN_FAIL;
if (signature == NULL)
{
return ATCA_BAD_PARAM;
}
do
{
// Build sign command
packet.param1 = mode;
packet.param2 = key_id;
if ((status = atSign(ca_cmd, &packet)) != ATCA_SUCCESS)
{
break;
}
if ((status = atca_execute_command(&packet, _gDevice)) != ATCA_SUCCESS)
{
break;
}
if (packet.data[ATCA_COUNT_IDX] > 4)
{
78: memcpy(signature, &packet.data[ATCA_RSP_DATA_IDX], packet.data[ATCA_COUNT_IDX] - ATCA_PACKET_OVERHEAD);
}
}
while (0);
return status;
}
As the attacker freely controls the packet.data[ATCA_COUNT_IDX] value it is possible to influence the number of bytes copied in the memcpy operation. Any packet.data[ATCA_COUNT_IDX] value greater than 67 will cause a buffer overflow to occur on the "signature" buffer. Moreover, any value greater than 195 will also cause uninitialized data to be copied as well.
Depending on the context of the software using "cryptoauthlib" it may be possible to corrupt important variables used in security controls, hijack the execution flow, or disclose information found in the stack / heap (depending on where packet.data is stored).
The issue was identified on firmware containing version "20190517" of cryptoauthlib.
Recommendation
The vulnerability has been patched in version "20191122" of the "cryptoauthlib" library. Affected manufacturers of embedded systems that use Microchip cryptographic co-processors are strongly recommended to upgrade to at least this version of the "cryptoauthlib" library.
Disclosure Timeline
| CVE Allocation: | September 9, 2019 |
| Vendor Contact: | September 11, 2019 |
| Vendor Confirmation: | October 1, 2019 |
| Vendor Fix Released: | November 23, 2019 |
| Public Advisory: | October 21, 2020 |