Describe the bug
In the working version of lora_receive, a buffer overflow vulnerability is present that would allow stack smashing in the caller. As this is an interface that goes between the inside and outside of the attack surface, this vulnerability is assumed to be (and very likely is) exploitable, as an attacker would have a tremendous amount of control over the data entering this buffer.
The cause of this bug is the dynamic nature of buffer_len_ptr in lora_receive. If the modem has more data in its FIFO than is present in the buffer passed in (for example, the LORA_MSG data structure), then lora_receive will write to an address beyond the length of the buffer, overwriting data.
To Reproduce
Transmit more data to the receiver than the size of its message data structure. The likely result will be a hardfault triggered by destruction of a stack canary, although I haven't tested this myself. Worst case scenario, we don't have proper stack canaries and due to the fact that binaries for the flight computer are not position independent, this is a hijackable vulnerability.
I encourage someone at SDR to try to successfully hijack execution either to shellcode or a known address in the binary that can produce a verifiable result (e.g. jump to a location where the led changes color or buzzer beeps) as a proof of concept. If someone can do this, you'll get added to the list of security SMEs (so basically an instant promotion lol). Feel free to disable canaries if they're present to try this out.
Expected behavior
The solution for this vulnerability is to simply pass a static buffer size and enforce writes to this buffer staying under this size.
Screenshots/Pictures/Video
N/A
Additional context
CWE-121, CWE-788.
For learning purposes, consider taking a look at this module from ASU's cybersecurity faculty: https://pwn.college/intro-to-cybersecurity/binary-exploitation/
Points of Contact
LoRa subject matter expert: @266-750Balloons
Security subject matter expert: @ETSells
Describe the bug
In the working version of lora_receive, a buffer overflow vulnerability is present that would allow stack smashing in the caller. As this is an interface that goes between the inside and outside of the attack surface, this vulnerability is assumed to be (and very likely is) exploitable, as an attacker would have a tremendous amount of control over the data entering this buffer.
The cause of this bug is the dynamic nature of buffer_len_ptr in lora_receive. If the modem has more data in its FIFO than is present in the buffer passed in (for example, the LORA_MSG data structure), then lora_receive will write to an address beyond the length of the buffer, overwriting data.
To Reproduce
Transmit more data to the receiver than the size of its message data structure. The likely result will be a hardfault triggered by destruction of a stack canary, although I haven't tested this myself. Worst case scenario, we don't have proper stack canaries and due to the fact that binaries for the flight computer are not position independent, this is a hijackable vulnerability.
I encourage someone at SDR to try to successfully hijack execution either to shellcode or a known address in the binary that can produce a verifiable result (e.g. jump to a location where the led changes color or buzzer beeps) as a proof of concept. If someone can do this, you'll get added to the list of security SMEs (so basically an instant promotion lol). Feel free to disable canaries if they're present to try this out.
Expected behavior
The solution for this vulnerability is to simply pass a static buffer size and enforce writes to this buffer staying under this size.
Screenshots/Pictures/Video
N/A
Additional context
CWE-121, CWE-788.
For learning purposes, consider taking a look at this module from ASU's cybersecurity faculty: https://pwn.college/intro-to-cybersecurity/binary-exploitation/
Points of Contact
LoRa subject matter expert: @266-750Balloons
Security subject matter expert: @ETSells