Talos Vulnerability Report

SUMMARY

A stack-based buffer overflow vulnerability exists in the securebio_identify functionality of Dell ControlVault3 5.14.3.0. A specially crafted malicious cv_object can lead to a arbitrary code execution. An attacker can issue an api call 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.

Broadcom BCM5820X
Dell ControlVault3 5.14.3.0
Dell ControlVault3 Driver and Firmware prior to 5.15.10.14
Dell ControlVault3 Plus Driver and Firmware prior to 6.2.26.36

PRODUCT URLS

ControlVault3 - https://dell.com/ BCM5820X - https://www.broadcom.com/products/embedded-and-networking-processors/secure/bcm5820x

CVSSv3 SCORE

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

CWE

CWE-121 - Stack-based Buffer Overflow

DETAILS

Dell ControlVault is a hardware based solution that can securely store passwords, biometric templates and security codes. It can interface with smart cards, Near-field Communication (NFC) devices and fingerprint readers. The hardware solution is based on the Broadcom BCM5820X chip series.

Context

On windows, any low privilege user can interface with the ControlVault3 hardware. In order to do so, a userland dll bcmbipdll.dll can be used to talk with the device driver cvusbdrv.sys which in turns talk over USB to the ARM firmware running on the BCM5820X chip implementing the secure context. First, a session needs to be created calling the cv_open function, which will return a pointer to a session object. This session object lives in a dedicated heap of ARM Firmawre. Then, arbitrary objects can be created with cv_create_object or imported using cv_import_object

Vulnerability

The function securebio_identify can be reached by a low privilege user by issuing an api call for the command 0x96 (CV_CMD_FEATURE_SET_AUTHENTICATED). Among the parameters this function takes, one is the handle for a cv_object provided by the user and related to the user’s session (created using cv_open). We can see the code do as follow:

int __fastcall securebio_identify(
        cv_session *objSession,
        int data1,
        int len1,
        int a4,
        unsigned __int8 *hmacRes,
        _DWORD *pLen,
        cv_obj_handle objHandle)
{
  int status_; // r7
  cv_status_e v11; // r0
  int status; // r0
  cv_identify_object *obj; // [sp+18h] [bp-108h] BYREF
  unsigned __int8 hmacRes_[32]; // [sp+1Ch] [bp-104h] BYREF
  unsigned __int8 data2[32]; // [sp+3Ch] [bp-E4h] BYREF
  cv_obj_properties objProperties; // [sp+5Ch] [bp-C4h] BYREF
  char ctx[132]; // [sp+9Ch] [bp-84h] BYREF

  memset(hmacRes_, 0, sizeof(hmacRes_));
  memset(data2, 0, sizeof(data2));
  if ( data1 && len1 )
  {
    phx_crypto_init(ctx);
    memset(&objProperties, 0, sizeof(objProperties));
    objProperties.session = objSession;
    objProperties.objHandle = objHandle;
    v11 = cvGetObj(&objProperties, &obj);   // [1]
    status_ = v11;
    if ( v11 )
    {
      log_stuff("Getting object failed : securebio_identify : status = %x", v11);
    }
    else
    {
      cvUpdateObjCacheLRU(objProperties.objHandle);
      cvFindObjPtrs(&objProperties, obj);
      memcpy(data2, objProperties.pObjValue, objProperties.objValueLength);// [2]
      status = securebio_hmac_cmd_identify(ctx, application_hmac_key, data1, len1, data2, 32, hmacRes_, 0x20u);
      status_ = status;
      if ( status )
      {
        log_stuff("\nsecurebio identify failed: status = %x", status);
      }
      else
      {
        *a4 = 4;
        memcpy((a4 + 4), data2, 32);
        memcpy(hmacRes, hmacRes_, 32);
        *pLen = 32;
      }
    }
  }
  else
  {
    status_ = 161;
    log_stuff("Invalid parameters : securebio_identify\n");
  }
  return status_;
}

We can see at [1] that an object provided by the user via the objHandle parameter is retrieved, and then used at [2] to copy the objectValue filed onto the data2 stack variable. This variable is an array of size 32-bytes. It is obvious that if the data copied at [2] is bigger than 32 bytes, then a stack-overflow will occur. While the various code path in cv_create_object limit the size of this field to something smaller than 32 bytes, it doesn’t appear to be the case if the object was imported via cv_import_object. Furthermore, a vulnerabilitly like the one described in TALOS-2024-XXXX allows to forge a cv_object with an arbitrary length for the objValue and objValueLength fields.

Consequences

A low privilege user (or an attacker with physical access) can interact with the firmware, create a malicious cv_object and trigger the securebio_identify functions to cause a stack overflow and gain control over the instruction pointer. Because the firmware does not implement ASLR and has some memory region marked as read-write-execute, this directly leads to arbitrary code execution within the secure firmware. Encryption keys and sensitive material can then be retrieved from the chip.

VENDOR RESPONSE

Vendor advisory: https://www.dell.com/support/kbdoc/en-us/000276106/dsa-2025-053

TIMELINE

2024-12-18 - Vendor Disclosure
2025-06-13 - Vendor Patch Release
2025-08-09 - Public Release