Espressif Response to BlueBorne Vulnerability?

[p-rimes]

After updating all computers and smartphones (Windows, Mac, Linux, iPhone, Android) with the latest updates to address the BlueBorne security vulnerability (everyone should have done this already!), we should ask what to do about IoT chips such as ESP32 that support Bluetooth and may be affected by the same vulnerability.

Detailed here by the IoT research team that discovered it:
https://www.armis.com/blueborne/
https://youtu.be/LLNtZKpL0P8

Is ESP32 affected by this vulnerability, and how severe is it? Can it lead to privilege escalation, and then to remote code execution (as in the major OS platforms)?

I assume binary blobs under Espressif control should be patched and distributed immediately. Can ESP32 devices which are already deployed be updated via OTA to patch this vulnerability? What steps can be taken by developers to limit the impact in the meantime? (e.g. powering off/disabling bluetooth radio automatically, logging BT connections, etc)

[Lucas.Hutchinson]

(Note: I am not a security researcher, or an espressif employee)

From my understanding of the attacks so far:
The vulnerabilities that relate to the exploitation of the BNEP service, and also the PAN profile of this service would not seem to affect the ESP32. As far as I can tell the ESP32 stack does not support this service or profile.

The vulnerabilities relating to SDP. Yes the ESP32 supports this service. Remote code execution on an embedded device with statically linked code would be pretty difficult, and i would think impossible (however I could be wrong). However the part of the vulnerability relating to accessing memory and or encryption keys may still be an attack vector.

This is just my 2c. Would be good to hear from espressif about this however.

[JustNopIt]

This is taking too long. Our company just got rid of all ESP32 chips. We are not going to take the risk of compromising all of our products.

[mgleason_3]

Out of curiosity, what are you using in instead?

[ESP_Angus]

Sorry for the delay in replying to this thread. If Bluetooth Classic is in use, meaning the Service Discovery Protocol server is enabled, ESP-IDF was vulnerable to the information leak described in ​CVE-2017-0785.

A fix has been merged to master branch on github today (as of commit a3a4a205) and will be in the forthcoming V3.0 release. The fix will also be backported to the V2.1 release branch (I'll post here when the backported change is available on github).

If you have a custom ESP-IDF fork and don't want to update to latest master then you can cherry-pick commit c9241b43 to get the fix.

The remaining "BlueBorne" bluedroid vulnerabilities are not in services that are supported or implemented in ESP-IDF:

• The RCE (remote code execution) vulnerabilities described (CVE-2017-0782 & CVE-2017-0781) are in BNEP (Bluetooth networking protocol) which isn't implemented in the ESP-IDF version of Bluedroid.
• The related access bypass vulnerabilities (CVE-2017-0783​ ​& CVE-2017-8628) are in the PAN Profile which is also part of the IP networking stack and is also not implemented in ESP-IDF.

[ESP_Angus]

A fix has been merged to master branch on github today (as of commit a3a4a205) and will be in the forthcoming V3.0 release. The fix will also be backported to the V2.1 release branch (I'll post here when the backported change is available on github).

The release/v2.1 branch has now also been updated (as of commit 3eeaae0). This fix will also be in the forthcoming V2.1.1 bugfix release.

[p-rimes]

OK, that is good news!

Just to confirm, will the regular OTA mechanism take care of these changes, once esp-idf has been updated and rebuilt?

[ESP_Angus]

OK, that is good news!

Just to confirm, will the regular OTA mechanism take care of these changes, once esp-idf has been updated and rebuilt?

That's right. Any app which is compiled against the updated ESP-IDF version will have the fix.