Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reproducing CVE_2019_13916 on (real) devices #4

Open
wuruoyu opened this issue Sep 28, 2020 · 1 comment
Open

Reproducing CVE_2019_13916 on (real) devices #4

wuruoyu opened this issue Sep 28, 2020 · 1 comment

Comments

@wuruoyu
Copy link

wuruoyu commented Sep 28, 2020

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
Copy link
Collaborator

bolek42 commented Sep 30, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants