How Do BadAlloc Flaws Compromise IoT Devices?

TL;DR

BadAlloc vulnerabilities let an oversized allocation request wrap around into a small value, causing malloc or calloc to report success with an undersized buffer. When an application then copies the expected amount of data, a buffer overflow can occur and potentially enable remote code execution. The flaws affected more than 20 widely used SDKs and real-time operating systems across millions of IoT and operational technology devices.

Transcript

Hi, everybody. Uh, I'm Omri. I'm a Security Researcher at Microsoft, the, at the Azure Defender for IoT group. Microsoft Defender for IoT group. We just changed our name. The new name. Yeah. And I'm Tamiar-- Tami Ariel, also a Security Researcher from, uh, Section Fifty Two. And today we're here to talk with you about badalloc, uh, which is a, a bu... Read More

Key Insights

• BadAlloc is a collection of vulnerabilities in memory allocators, primarily within real-time operating systems and SDKs used by IoT and operational technology devices. The researchers identified more than 25 CVEs across more than 20 implementations, including software associated with consumer, medical, industrial, and control-system environments.
• Integer overflow is the underlying arithmetic problem. On a 32-bit calculation, adding eight to the maximum unsigned integer wraps the result to seven, while multiplying two by a value just above half the representable range can wrap the result to two.
• Memory allocators reserve more space than callers explicitly request because they may store metadata, such as the allocation size, alongside the returned buffer. If adding that metadata overflows the integer range, the allocator can reserve a much smaller block than the application expects.
• Calloc introduces an additional overflow risk because it multiplies the number of elements by the size of each element. Without checking that multiplication, a request for a large array can become a small allocation while still appearing successful to the calling application.
• A buffer overflow occurs when application code trusts the requested allocation size after a vulnerable allocator returns success. The application may copy the full attacker-controlled input into the unexpectedly small buffer, overwriting adjacent memory and potentially creating a path to remote code execution.
• Vulnerable implementations appeared in widely deployed platforms, including VxWorks, QNX, FreeRTOS, NXP MQX, Google IoT device software, and Redis. VxWorks itself estimated that its real-time operating system ran on roughly two billion devices, illustrating the potential deployment scale.
• Some BadAlloc flaws were likely present from the earliest versions of affected software. The researchers found an online VxWorks version dating to 1993 and a kLIBC source comment from 2002 explicitly noting that multiplication overflow should be checked, although the issue remained.
• The researchers built a proof of concept using a Texas Instruments SimpleLink chip, its SDK, the POSIX allocation layer, and FreeRTOS. The platform also offered Wi-Fi, Bluetooth, Zigbee, other radio communications, and plugin connections to cloud providers and voice APIs.

Questions & Answers

Q: What is the BadAlloc vulnerability?

BadAlloc is the name given to a collection of memory-allocation vulnerabilities found in more than 20 widely used SDKs and real-time operating systems. The affected malloc and calloc implementations can perform size calculations without checking for integer overflow. A huge request may therefore wrap around to a small value, return successfully, and leave an application with a buffer far smaller than it expects.

Q: How does integer overflow cause a BadAlloc flaw?

Integer overflow occurs when an arithmetic result exceeds the range available to the calculation. On a 32-bit system, adding eight to the maximum unsigned integer wraps around to seven. An allocator that adds metadata bytes without checking the result may consequently reserve only a few bytes for a massive request, while the calling application treats the allocation as successful and correctly sized.

Q: Why can calloc be vulnerable to integer overflow?

Calloc receives an element count and an element size, then multiplies them to determine the required allocation. On a 32-bit system, that multiplication can exceed the representable range and wrap around to a small result. If the implementation does not validate the calculation, it can allocate a tiny buffer even though the caller requested a very large array, creating conditions for an overflow.

Q: How can BadAlloc lead to a buffer overflow?

An application commonly requests memory, checks whether the allocator returned success, and then copies data into the resulting buffer. With BadAlloc, an oversized request can wrap around and produce a much smaller successful allocation. The application may then copy the original amount of attacker-controlled data into that small buffer, writing beyond its boundary and potentially enabling remote code execution.

Q: Which operating systems and SDKs were affected by BadAlloc?

The researchers identified affected implementations across more than 20 widely used SDKs and real-time operating systems, covering more than 25 CVEs. Named examples included VxWorks, QNX, FreeRTOS, NXP MQX, Google IoT device software, and Redis. The affected technologies appeared in consumer, medical, industrial IoT, and industrial control system environments, as well as 32-bit Redis deployments.

Q: Why is BadAlloc especially significant for older IoT devices?

Some affected allocator implementations appeared to contain the vulnerable arithmetic from their earliest versions. The researchers found an online VxWorks release dating to 1993 and said flaws in VxWorks, NXP MQX, and similar systems were likely present from day one. Because old devices can remain deployed, correcting current software does not automatically remove vulnerable legacy products already operating in the field.

Q: How did the researchers demonstrate BadAlloc exploitation?

The researchers first illustrated a server that allocates a buffer and copies user data after checking whether allocation succeeded. A normal allocator rejects an excessively large request, but a vulnerable allocator can accept it after the size wraps around. They also developed a proof of concept on a Texas Instruments SimpleLink chip using its SDK, POSIX layer, and FreeRTOS.

Q: What makes custom memory allocators risky in this context?

Custom allocators must correctly handle every size calculation required for allocation metadata and array dimensions. The examples showed implementations using an addition or multiplication result immediately without checking whether it remained logical after overflow. Redis was affected because it implemented its own allocator for cross-platform compatibility, and the researchers demonstrated remote code execution against Redis running on 32-bit systems before the issue was fixed.

Summary & Key Takeaways

• BadAlloc describes memory-allocation vulnerabilities caused by unchecked integer overflow in malloc and calloc implementations. Allocators add metadata or multiply array dimensions before reserving memory. On 32-bit systems, these calculations can wrap around, producing a small allocation even though the caller requested a very large buffer and received an apparent success result.

• An application may verify only whether allocation succeeded before copying attacker-controlled data into the returned buffer. A vulnerable allocator can accept a huge request, reserve far less memory than expected, and allow the subsequent copy to overflow the buffer. The researchers demonstrated this pattern and reported remote code execution on 32-bit Redis systems.

• The researchers found the flaw across more than 20 widely used SDKs and real-time operating systems, covering more than 25 CVEs. Examples included VxWorks, QNX, FreeRTOS, NXP MQX, Google IoT device software, and Redis. Some vulnerable implementations appeared to date back to their earliest available versions, complicating remediation for older devices.