This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640: BlueBorne Attack Vector

Part Number: CC2640
Other Parts Discussed in Thread: BLE-STACK

I'm curious if TI has evaluated the vulnerability of the SimpleLink MCU's to the recently disclosed BlueBorne Attack Vector? 

More info here: https://www.armis.com/blueborne/

The Armis post focuses mostly on your traditional central devices, phones, PC's, etc., and is a little light on technical details, but it sounds like nearly any Bluetooth device could potentially be affected. They discuss an array of vulnerabilities found so far and hint that there are many more to be discovered/revealed. This would obviously apply to BR/EDR devices as well, but for my purposes I need to know if the CC2640 is affected?

  • Hello Joshua,

    TI has reviewed the "BlueBorne" white paper published by Armis Labs. In regards to the CVEs published in the white paper which I have listed below:

    • Linux kernel RCE vulnerability - CVE-2017-1000251
    • Linux Bluetooth stack (BlueZ) information Leak vulnerability - CVE-2017-1000250
    • Android information Leak vulnerability - CVE-2017-0785
    • Android RCE vulnerability #1 - CVE-2017-0781
    • Android RCE vulnerability #2 - CVE-2017-0782
    • The Bluetooth Pineapple - Logical Flaw CVE-2017-0783 & CVE-2017-8628
    • RCE in Apple’s Low Energy Audio Protocol - CVE-2017-14315

    Based on our review, our assessment is these vulnerabilities/exploits are not applicable to the TI BLE-Stack running on our CC254x, CC26xx and CC13xx family of BLE wireless MCUs. More specifically, these CVEs pertain to implementations of Bluetooth Classic (BR/EDR) protocol stack components on the host OS systems listed in the white paper (i.e., Windows, Linux, Android, Tizen and pre Apple iOS 10). Our BLE MCUs do not implement classic Bluetooth (BR/EDR) or any of these host operating systems. In CVE-2017-14315, the published exploit requires a classic BT connection according to the white paper (in addition to supporting Apple’s Low Energy Audio Protocol). Lastly, the white paper did not demonstrate any vulnerability with the Bluetooth protocol (Classic or LE) itself, but rather how these host systems have implemented components/applications of or on top of the protocol stack.

    It is important to remember that the security of end equipment is the customer’s responsibility and requires system designers to carefully design, validate, and test actual applications at each stage of development, taking into conditions those applications may encounter. You can learn more about TI’s Security Enablers to help you develop SimpleLink applications at www.ti.com/security.

    Best wishes

  • Many of the above vulnerabilities are based on buffer overflows.

    Armis also makes the following statement on their web site:

    "Armis Labs has identified eight zero-day vulnerabilities so far, which indicate the existence and potential of the attack vector. Armis believes many more vulnerabilities await discovery in the various platforms using Bluetooth."

    What sort of tools and techniques does TI use to validate that they don't have similar sorts of unidentified weaknesses in their stack code?

    Has TI considered a third party analysis of their code certifying the level of security that it provides?
  • These broad statements can apply to any software, be it Bluetooth or any wired/wireless implementation. This further stresses the need to thoroughly test the product at the system level. Although we do follow internal software development practices, we do not provide these details through our E2E forums. If you have a specific issue with a particular test result, please do feel free to bring this to our attention so we can help address with our technical experts.

    Best wishes