SUMMARY

An integer overflow vulnerability exists in the _A_DecodeType functionality of Dell BSAFE Crypto-C xxx. A specially crafted ASN.1 record can lead to an out-of-bounds read. An attacker can provide malformed ASN.1 record to trigger this vulnerability.

CONFIRMED VULNERABLE VERSIONS

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Dell BSAFE Crypto-C RSA 6.4

PRODUCT URLS

BSAFE Crypto-C - https://www.dell.com/support/product-details/en-us/product/bsafe-crypto-c-micro-edition/docs

CVSSv3 SCORE

7.5 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CWE

CWE-190 - Integer Overflow or Wraparound

DETAILS

Dell BSAFE Crypto-C is a software library providing cryptographic functions and services for application developers. It is part of the BSAFE suite of security products, designed to offer robust encryption and data protection capabilities. Crypto-C supports a wide range of cryptographic algorithms, including symmetric and asymmetric encryption, hashing, and digital signatures, ensuring secure data handling and communication.

An integer overflow vulnerability exist in _A_DecodeType. We can see usage of this vulnerable function among the others in getRSAPublicModLen which eventually calls GetIndefiniteElementLen, which has the following loop.

Line 1	for (i = 0; !(contents.data[i] == 0 && contents.data[i + 1] == 0);
Line 2	   i += subElementLen) {
Line 3	if ((status = _A_GetIndefiniteElementLen
Line 4		(&subElementLen, contents.data + i, maxLen - (i + extraBytes))) != 0)
Line 5	  return status;
Line 6
Line 7	}

GetIndefiniteElementLen can update subElementLen via a call to _A_DecodeType, with the source snippet below. Malformed ASN data can specify a large value of len that causes an integer overflow in the expression in line 118. This subsequently causes a read out-of-bounds when i += subElementLen and !contents.data[i] == 0 are executed above.

Line 100	int _A_DecodeType(unsigned int *encodingLen, unsigned int *type,
Line 101	  unsigned int *extendedTagLen, ITEM *contents, byte *encoding,
Line 102	  unsigned int maxLen)
Line 103
Line 104	{
Line 105
Line 106	...
Line 107
Line 108	  else if (sizeof(unsigned int) >= 4 && lengthOctets[0] == 0x84)
Line 109	  {
Line 110		if (maxLen < *extendedTagLen + 6)
Line 111		 /* Not enough bytes to read the length. */
Line 112		  return (ASNE_InputLen);
Line 113
Line 114		contents->len = ((unsigned int)lengthOctets[1] << 24) |
Line 115						((unsigned int)lengthOctets[2] << 16) |
Line 116						((unsigned int)lengthOctets[3] << 8) |
Line 117						 (unsigned int)lengthOctets[4];
Line 118		*encodingLen = 6 + contents->len + *extendedTagLen;
Line 119		contents->data = lengthOctets + 5;
Line 120
Line 121	  }
Line 122	... 
Line 123	  if (*encodingLen > maxLen)
Line 124		return (ASNE_InputLen);

If an attacker is successful, they could use the leaked memory to bypass ASLR and, in combination with other vulnerabilities, gain the ability to execute arbitrary code.

VENDOR RESPONSE

Vendor information: https://www.dell.com/support/kbdoc/en-us/000205186/bsafe-crypto-c-micro-edition-sdk-end-of-life-announcement

TIMELINE

2025-01-24 - Vendor Disclosure
2025-10-08 - Vendor Patch Release
2025-10-16 - Public Release