pbarry25 (12)

This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.

Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit can leave the target in a crashed state or force a restart, triggered by sending the vulnerable device Logical Link Control and Adaptation Layer Protocol (L2CAP) packets containing a Link Layer Length (LL Length) value less than L2CAP Length + 4, resulting in a Buffer Overflow (BOF) condition on the target. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. Due to the nature of the vulnerability being a BOF leaves the door open for further exploration to potentially gain code execution on a vulnerable target. It appears the SoC manufacturer has issued some fixes for their vulnerable SDK(s).

EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.

This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.

Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit can leave the target in a crashed state or force a restart, triggered by sending the vulnerable device packets with very large Link Layer Length (LL Length) values which eventually results in a Buffer Overflow (BOF) condition. In their testing, researchers were able to trigger a crash->restart on an Eve Energy smart plug containing this vulnerability, triggering power interruption to whatever is plugged into the vulnerable plug due to the target’s logic keeping AC power off while the device is starting up. Researchers also tested against an August Smart Lock, which uses the same SoC and contains the same vulnerability. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. Due to the nature of the vulnerability being a BOF leaves the door open for further exploration to potentially gain code execution on a vulnerable target. It appears the SoC manufacturer has issued some fixes for their vulnerable SDK(s).

EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.

This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.

Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit can leave the target in a deadlocked state (in this case, stuck in the ‘idle’ state), triggered by sending the vulnerable device either a truncated connection request OR a connection request with invalid ‘interval’ or ‘timeout’ values of 0. While the condition of being stuck in the ‘idle’ state should be handled by the application layer (and transitioned to another state), not all devices correctly do so (at least one instance of ‘example code’ provided with the SDK did not handle this condition). In their testing, researchers were able to deadlock a eGeeTounch smart luggage lock containing this vulnerability, requiring a powercycle to resume normal operation. A detailed explanation can be found here in the original disclosure. It appears the SoC manufacturer has issued fixes for their vulnerable SDK(s).

EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.

This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.

Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit will leave the target in a deadlocked state, triggered by sending two consecutive Attribute Protocol (ATT) request packets during a connection event. If a watchdog or similar mechanism is enabled, an exploited target may restart without intervention (otherwise, a hard powercycle may be required). A detailed explanation can be found here in the original disclosure. It is unclear if the SoC manufacturer has issued fixes for their vulnerable SDK(s).

EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.

This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.

Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit will leave the target in a crashed or non-functional state via a Buffer Overflow (BOF), triggered by sending a packet with a large Link Layer Length value. While a simple attack results in a denial-of-service (DoS), the nature of the vulnerability being a BOF leaves the door open for further exploration to potentially gain code execution on a target. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. It appears the SoC manufacturer has issued fixes for their vulnerable SDK(s).

Related, the same researchers found an SoC from Cypress which also contained a similar vulnerability (CVE-2019-16336), also disclosed as part of SweynTooth.

EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.

This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.

Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit will leave the target in a crashed or non-functional state via a Buffer Overflow (BOF), triggered by sending a packet with a large Link Layer Length value. While a simple attack results in a denial-of-service (DoS), the nature of the vulnerability being a BOF leaves the door open for further exploration to potentially gain code execution on a target. In their testing, researchers were able to crash a FitBit Inspire device containing this vulnerability, which resulted in an immediate reboot of the device. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. It appears the SoC manufacturer has issued fixes for their vulnerable SDK(s).

Related, the same researchers found an SoC from NXP which also contained a similar vulnerability (CVE-2019-17519), also disclosed as part of SweynTooth.

EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.