search

seemoo-lab / frankenstein

Broadcom and Cypress firmware emulation for fuzzing and further full-stack debugging
Apache License 2.0
428 stars 65 forks source link

Reproducing CVE_2019_13916 on (real) devices #4

Open wuruoyu opened 3 years ago

wuruoyu commented 3 years ago

Hi,

I watched the presentation at Usenix Security and it is wonderful! It is great to have a firmware emulator, which is capable of finding so many CVEs.

I noticed that the reproduction of CVE_2019_13916 in README is only for the emulator. I am wondering if you can provide the POC of this CVE to attack the real device (say, a modified CYW20735 to attack Raspberry Pi). I have tried using loadelf projects/CYW20735B1/gen/CVE_2019_13916.patch in modified InternalBlue and then invoking while true; do hcitool -i hci1 lecc BLE_ADDR; done, where BLE_ADDR is the BLE MAC Address of an advertising Raspberry pi. However, it seems to be that it does not work.

Could you please provide a POC or instructions on how to trigger CVE_2019_13916 on the real device. Very appreciate your help!

Respectfully, Ruoyu

bolek42 commented 3 years ago

Hi Ruoyu Thanks for your feedback! Hope it will be useful to you.

Well, I guess you have pointed out a bug. The code from the PoC was originally running inside a WICED application. This is an IDE to develop Bluetooth Low Energy applications. In that case, the PoC will perform the required patches and as soon as you connect to the device, a BLE PDU is sent by the app, triggering the bug.

As this method of installing the patch requires to run btattach on the evalboard, the device is running as a BT adapter and not as a BLE device. In theory, you need to load the patch, establish a BLE connection, and send a PDU. However, I don't know a straightforward way to do so right now. I'll try to patch this these days. Also, those static addresses need to be replaced with symbols...

To trigger the overflow it is sufficient to send a 255byte BLE PDU. The only special thing the PoC does is to control the 4th byte of the overflow. You have to debug the heap to notice the overflow happens as there is no other feedback. (The s10e adapter crashed as since ~2019 Broadcom implements a basic heap sanitizer, but the bug is patched now.) As in CVE-2019-11516 you need to allocate three buffers at once to cause a crash, however, until now we did not manage to do so. This is the reason, why this bug is a memory corruption and not an RCE right now. If you have an idea you are welcome to share it (:

thanks and best regards, Jan