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
sock_dns: Security issues (including remote code execution) #10739
Comments
|
@nmeum since this is a severe security flaw, we would have preferred some undisclosed heads up via |
|
(there is no |
|
I'm AFK, can take a look later tonight. |
|
@kaspar030 already on it. I can't reproduce the crash on native but from my debugging I would think it is just the enormous address space available there ;-). |
|
(I see that the |
|
Confirmed on |
|
Fixed in #10740 |
Fixes RIOT-OS#10739 (cherry picked from commit 2840b38)
Fixes RIOT-OS#10739 (cherry picked from commit 2840b38)
Description
gnrc_sock_dnsdoesn't perform sufficient sanity checks on the DNSresponse it receives from the configured DNS server.
Here is a non-exhaustive list of issues:
QDCOUNTcontained in the DNS response is not verified. Thiscauses an out-of-bounds buffer access in the
_skip_hostnamefunction ifQDCOUNTis set to a value larger than the buflensupplied to_parse_dns_reply.RDLENGTHbounds-check for the answer section is incorrect fortwo reasons: (a)
buf + lenis the first invalid address, so>=needsto be used as a comparison operator (b) The result of
bufpos + addrlenmight cause a pointer overflow (especially due to the fact that
addrlenis attacker controlled). If pointer overflows wrap around(undefined behaviour) this would allow an attacker to circumvent the
bounds-check and exposes a buffer overflow vulnerability since the
attacker controlled
addrlenis later used inmemcpy(addr_out, bufpos, addrlen), potentially allowing a code execution.addr_outis not passed tothe
_parse_dns_replyfunction at all. This makes checking whether theattacker controlled address actually fits in the buffer impossible and
allows an easy buffer overflow and potential code execution.
All of these are especially critical due to the fact that DNS responses
can easily be spoofed, especially since all spoofing protection mechanisms
of DNS were not implemented. So an attacker doesn't even need to control the
configured DNS server in order to exploit this.
Steps to reproduce the issue
tests/gnrc_sock_dnsto your RIOT node.Causing a crash
Constantly send a DNS response with an excessive qdcount on the computer
associated with the IP-Address you configured in the radvd RDNSS
definition. For example
Remote code execution
This is (obviously) highly platform specific. We did
this with
BOARD=pba-d-01-kw2x. We wrote some ARM assembler code whichtoggles the LED and stored the machine code for it in the
RDATAfieldof the answer section in the DNS response, thereby overflowing the
addrbuffer in themainstack frame. Our payload exactly fits intothe stack frame of the main function and overwrites the return address
of that function, jumping to the
addrbuffer and executing ourpayload.
Exploit written by @pyropeter. See: https://github.com/beduino-project/exploit-riot-dns
We also working on documenting how to adapt the payload for slightly different binaries (depending on toolchain, board, … the exploit might not work because of hardcoded memory addresses).
Versions
RIOT-Version: 5e03f58
Build environment:
The text was updated successfully, but these errors were encountered: