"BadAlloc" RTOS Integer overflow vulnerability

- Posted in Vulnerability by

BadAlloc is the name for a related group of RTOS (Real Time Operating System) vulnerabilities that target 25 platforms, with 23 related vulnerabilities. The result of the vulnerability being exploited varies based upon the target device/platform, but can vary from high hardware usage, limiting the operations of said affected device, to device firmware crashes and reboots. The vulnerability exploits a flaw in memory allocation within the device to achieve the above fault.

The error occurs in a range of IoT and ROT devices as well as Blackberry devices used in maritime and other government operations. A remote attacker could exploit CVE-2021-22156 to cause a denial-of-service condition or execute arbitrary code on affected devices, and in our review on the dark web, has been linked to malware designed to connect additional CPU power to bitcoin mining.

The issue was discovered in April 2021, but many devices still remain unpatched after the August 17 report at Cert USA. Many of the devices unpatched have mitigation responses that recommend to isolate the unit from the internet or simply take it offline until a patch is released or it is replaced.

Cert USA states:

  • Apply available vendor updates.
  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available.
  • Also recognize VPN is only as secure as its connected devices.

We would add:

  1. Replace the device if possible
  2. IoT devices with this vulnerability have been linked to exploit attacks for bitcoin malware, and care should be taken to reset the device to factory defaults once secured to be absolutely sure the system is clean.

This discovery has been credited by CISA to David Atch, Omri Ben Bassat, and Tamir Ariel from Microsoft Section 52.

Here is a listing of the affected operating systems and their status:

Amazon FreeRTOS, Version 10.4.1 Update available

Apache Nuttx OS, Version 9.1.0 Update available

ARM CMSIS-RTOS2, versions prior to 2.1.3 Update in progress

ARM Mbed OS, Version 6.3.0 Update available

ARM mbed-ualloc, Version 1.3.0 no longer supported and no fix will be issued

BlackBerry QNX SDP Versions 6.5.0 SP1 and earlier Update available

BlackBerry QNX OS for Safety Versions 1.0.1 and earlier safety products compliant with IEC 61508 and/or ISO 26262 Update available

BlackBerry QNX OS for Medical Versions 1.1 and earlier safety products compliant with IEC 62304 Update available

Cesanta Software Mongoose OS, v2.17.0 Update available

eCosCentric eCosPro RTOS, Versions 2.0.1 through 4.5.3 Update available

Google Cloud IoT Device SDK, Version 1.0.2 Update available

Media Tek LinkIt SDK, versions prior to 4.6.1 Vendor will directly provide the fix, fix not available for free users

Micrium OS, Versions 5.10.1 and prior Update available

Micrium uC/OS: uC/LIB Versions 1.38.xx, Version 1.39.00 Update available

NXP MCUXpresso SDK, versions prior to 2.8.2 Update available

NXP MQX, Versions 5.1 and prior Update available

Redhat newlib, versions prior to 4.0.0 Update available

RIOT OS, Version 2020.01.1 Update available

Samsung Tizen RT RTOS, versions prior 3.0.GBB Update available

TencentOS-tiny, Version 3.1.0 Update available

Texas Instruments CC32XX, versions prior to 4.40.00.07 Update available

Texas Instruments SimpleLink MSP432E4XX Update available

Texas Instruments SimpleLink-CC13XX, versions prior to 4.40.00 Update available

Texas Instruments SimpleLink-CC26XX, versions prior to 4.40.00 Update available

Texas Instruments SimpleLink-CC32XX, versions prior to 4.10.03 Update available

Texas Instruments SimpleLink MSP432E4 No update currently planned

Uclibc-NG, versions prior to 1.0.36 Update available

Windriver VxWorks, prior to 7.0 Update in progress

Zephyr Project RTOS, versions prior to 2.5 Update available

BRAKTOOTH: Causing Havoc on Bluetooth Link Manager

- Posted in Vulnerability by

Bluetooth Classic (BT) protocol is a widely used wireless protocol in laptops, handheld devices, and audio devices. In the past few years, Bluetooth has come under scrutiny due to the discovery of several critical vulnerabilities. In this report, the authors disclose BrakTooth, a family of new security vulnerabilities in commercial BT stacks that range from denial of service (DoS) via firmware crashes and deadlocks in commodity hardware to arbitrary code execution (ACE) in certain IoTs.

As of the report date, 16 different vulnerabilities, which impact billions of devices that rely on Bluetooth Classic (BT) for communication have been uncovered. According to an academic paper from the University of Singapore, the bugs are found in the closed commercial BT stack used by at least 1,400 embedded chip components, that can lead to a host of attack types – mainly denial of service (DoS) via firmware crashes (the term “brak” is actually Norwegian for “crash”). One of the bugs can also lead to arbitrary code execution (ACE).

The team analyzed 13 pieces of BT hardware from 11 vendors; so far, there have been 20 CVEs assigned across them; with four vulnerabilities pending CVE assignments from Intel and Qualcomm. Some of the bugs are patched, others are in the process of being patched; but, researchers said in the paper, “it is highly probable that many other products (beyond the ≈1400 entries observed in Bluetooth listing) are affected by BrakTooth,” including BT system-on-chips (SoCs), BT modules or additional BT end products.

Potentially, billions of devices could be affected worldwide. BrakTooth report by Asset Group

Illustration of BT connection process

Figure 1: An Illustration of the BT connection procedure. FHS stands for Frequency Hopping Synchronization, ID stands for Identity, LMP stands for Link Manager Protocol and ACL stands for Asynchronous Connection Less.

Poc setup

Figure 2: An Illustration of BrakTooth attack scenario

Figure 2 showcases the generic scenario in which BrakTooth attacks are performed. The attacker only requires (1) a cheap ESP32 development kit (ESP-WROVER-KIT [37]) with a custom (non-compliant) LMP firmware and (2) a PC to run the PoC tool. The PoC tool communicates with the ESP32 board via serial port (/dev/ttyUSB1) and launches the attacks according to the specified target BDAddress () and exploit name parameter ().

Furthermore, the PoC tool logs over-the-air (OTA) packets and checks the health of the target by getting a paging timeout (no response) or alternatively getting status directly from the target via a serial port, ssh connection, etc.

Researchers successfully forced ESP32 into erasing data housed in devices’ non-volatile random-access memory (NVRAM), which retains data without applied power. They were also able to disable both BT and Wi-Fi on the device; and most concerningly, control the general-purpose input/output (GPIO) of the device if the attacker knows addresses to attached functions-controlling actuators. GPIO is used to communicate the ON/OFF signals received from connected switches, or the digital readings received from connected sensors, to the CPU.

“This has serious implications if such an attack is applied to Bluetooth-enabled smart home products,” the researchers warned.

Second form of atatck - Laptops and devices The second attack scenario can lead to DoS in laptops and smartphones. Researchers were able to achieve this using gear containing Intel AX200 SoCs and Qualcomm WCN3990 SoCs.

One of the DoS bugs (CVE-2021-34147) exists because of a failure in the SoC to free resources upon receiving an invalid LMP_timing_accuracy_response from a connected BT device (i.e., a “slave,” according to the paper:

“The attacker can exhaust the SoC by (a) paging, (b) sending the malformed packet, and (c) disconnecting without sending LMP_detach,” researchers wrote. “These steps are repeated with a different BT address (i.e., BDAddress) until the SoC is exhausted from accepting new connections. On exhaustion, the SoC fails to recover itself and disrupts current active connections, triggering firmware crashes sporadically.”

The researchers were able to forcibly disconnect slave BT devices from Windows and Linux laptops, and cause BT headset disruptions on Pocophone F1 and Oppo Reno 5G smartphones.

A third possible attack - Audio attacks A third attack scenario was discovered while probing various BT speakers (specifically the Mi Portable Bluetooth Speaker – MDZ-36-DB, BT Headphone and BT Audio Modules) and an unbranded BT audio receiver.

They all are variously subject to a series of bugs (CVE-2021-31609 andCVE-2021-31612, failures when sending oversized LMP packets; CVE-2021-31613, truncated packets; CVE-2021-31611, starting procedures out-of-order; and CVE-2021-28135, CVE-2021-28155 and CVE-2021-31717, feature response flooding).

Successful exploits can “freeze” devices, requiring the user to manually turn on unresponsive devices afterwards. For the Xiaomi MDZ-36-DBs and JBL TUNE 500BTs, this can be done while the user is actively playing music, researchers noted.

“Although issues were found in SoCs targeted to audio products, the BT implementation can be reused in a number of SoCs destined to different BT products,” they added.

These are just a few of the possible exploit scenarios.