Zephyr RTOS Fixes Bluetooth Bugs That May Lead to Code Execution
The Zephyr real-time operating system (RTOS) for embedded devices received an update earlier this month that fixes multiple vulnerabilities that can cause a denial-of-service (DoS) condition and potentially lead to remote code execution.
The issues were discovered in Zephyr’s Bluetooth LE Link Layer (LL) and its implementation of the Logical Link Control and Adaptation Protocol (L2CAP).
Despite being a small open-source project, Zephyr is backed by big names in the industry like Facebook, Google, Intel, Nordic Semiconductors, and Adafruit.
The operating system supports more than 200 boards with various CPU architectures (ARM, Cortex-M, Intel x86, ARC, NIOS II, Tensilica Xtensa, SPARC V8, RISC-V 32), making it an attractive choice for makers of small embedded devices (hearing aids, smart tags, distancing trackers, safety pods for smart PPE, IoT gateways, portable backup devices).
Bugs exploitable with a single packet
Matias Karhumaa, a senior software engineer at Synopsys, an American electronic design automation (EDA) company, found eight vulnerabilities in Zephyr after testing the lowest layers of the operating system’s Bluetooth LE stack.
The flaws are all in the Bluetooth LE Link Layer and the L2CAP implementation. Most of them affect Zephyr versions 2.5.0 and 2.4.0; some are also present in version 1.14.
Exploiting most of them prevents the vulnerable device from working either by causing them to freeze or misbehave in a way that prevents other systems from connecting to it.
Also Read: The DNC Singapore: Looking At 2 Sides Better
In a report today, Synopsys says that freezing the device may lead to remote code execution under certain circumstances and that attackers can trigger the condition on vulnerable devices over the air using a single packet.
In the case of one vulnerability (CVE-2021-3435, high severity score), exploiting it causes an information leak that could include sensitive details. By sending one malformed L2CAP_CREDIT_BASED_CONNECTION_REQ packet, an attacker can read up to 6 bytes of uninitialized memory content.
Another high-severity vulnerability is tracked as CVE-2021-3455. It causes a DoS condition on the system but also has the potential for remote code execution by exploiting a use-after-free issue in Zephyr’s L2CAP implementation.
CVE ID | Severity score | Impact | Host / Controller | Description |
CVE-2021-3430 | 5.9 (Medium) | Freeze (Zephyr 2.5.0, 2.4.0, 1.14) | Controller | Assertion failure on repeated LL_CONNECTION_PARAM_REQ |
CVE-2021-3431 | 5.9 (Medium) | Freeze (Zephyr 2.5.0, 2.4.0) | Controller | Assertion failure on certain repeated LL packets |
CVE-2021-3432 | 5.9 (Medium) | Freeze (Zephyr 2.5.0, 2.4.0, 1.14) | Controller | Invalid interval in CONNECT_IND leads to Division by Zero |
CVE-2021-3433 | 3.9 (Low) | Deadlock (Zephyr 2.5.0, 2.4.0, 1.14) | Controller | Invalid channel map in CONNECT_IND results to Deadlock |
CVE-2021-3434 | 7.7 (High) | Freeze (Zephyr 2.5.0, 2.4.0) | Host | L2CAP: Stack based buffer overflow in le_ecred_conn_req() |
CVE-2021-3435 | 5.9 (Medium) | Information leak (Zephyr 2.5.0, 2.4.0) | Host | L2CAP: Information leakage in le_ecred_conn_req() |
CVE-2021-3454 | 5.9 (Medium) | Freeze (Zephyr 2.5.0, 2.4.0) | Host | L2CAP: Truncated L2CAP K-frame causes assertion failure |
CVE-2021-3455 | 7.7 (High) | Freeze (Zephyr 2.5.0, 2.4.0) | Host | Disconnecting L2CAP channel right after invalid ATT request leads to use-after-free |
Technical details are available in Karhumaa’s post. The engineer found the first Bluetooth-related vulnerabilities in Zephyr RTOS in early February and reported them privately to the developer.
Also Read: 4 Best Practices on How to Use SkillsFuture Credit
A new Zephyr version, 2.6.0 has been released at the beginning of the month to include fixes for all the security vulnerabilities in the table above.
“Product manufacturers using the Zephyr OS in their product are encouraged to update their Zephyr version to include latest security fixes. Zephyr’s security policy guarantees that security patches are backported to the two most recent releases and to active LTS release,” Karhumaa writes.
“For non-LTS Zephyr versions, manufacturers may need to take care of backporting the security patches themselves,” the engineer added.
0 Comments