[Potential] Security Vulnerabilities within crosscoap

[bsmelo]

Hello developers of crosscoap,

My name is Bruno, and I'm an MSc. student in Brazil within the Institute of Computing from the University of Campinas. As part of my research on the application of fuzzing techniques for robustness and security black-box testing of CoAP implementations, I've tested your library. The sample used in my research was compiled from distribution/commit ddcc806 @ 2017-02-13. The application used to test it was go/bin/crosscoap.

I'm contacting you because the application mentioned above was one of the samples for which our tool was able to detect robustness and/or security issues. In a broad sense, every failure we found can actually be classified as a security vulnerability, because they impact availability --- the application either aborts or needs forceful restart in order to restore servicing CoAP requests. However, we didn't go as far as performing a thorough root-cause analysis for those failures, since it would be unfeasible for us (more than 100 failures were detected across 25 samples, each one using a different CoAP library, spanning 8 programming languages) and thus out-of-scope of this particular research.

We think that one of our main contributions is the opportunity to make a real-world impact on IoT security by reporting those failures to CoAP libraries' maintainers, with a comprehensible and easy way to replicate them so developers can further investigate and fix those failures. So, in order to follow up with a responsible disclosure process, we ask for a proper e-mail address (or any other form of contact) so we can send you:

• A script to reproduce the failures;
• A pcap file used by the script, containing the packets causing the failures;
• A logfile with the stacktraces we got for each reported failure.

We expect a reply anytime soon. Please let us know if which form of contact should we use --- or if it's ok to use this channel.

Thanks & Regards, Bruno Melo.

[dubek]

Hi Bruno, thank you for this effort. Where can I learn more about the efforts, the type of fuzzing, how do you check the targets, etc?

You can use this channel.

Note that crosscoap doesn't implement protocol parsing - we use go-coap and Go's internal HTTP stack. The issues may be related to these libraries.

[bsmelo]

Hi Bruno, thank you for this effort. Where can I learn more about the efforts, the type of fuzzing, how do you check the targets, etc?

A short-paper published last November is available in [1], but that was more of a presentation of the idea and preliminary rough results. These details you ask will be available in my MSc. thesis (to be finished this month), and the tool itself will also be released (in 2-3 weeks tops, I hope).

You can use this channel.

Reports in the next message.

Note that crosscoap doesn't implement protocol parsing - we use go-coap and Go's internal HTTP stack. The issues may be related to these libraries.

Yes, I know... That is one of the contributions we hope to get from developers/maintainers regarding the "investigation"/"root-cause analysis" we mentioned before. If that is the case after you have a look at it, we will proceed to report this to the go-coap developers.

[1] https://www.lasca.ic.unicamp.br/paulo/papers/2017-SBSeg-bruno.melo-CoAP-fuzzing.pdf

[bsmelo]

We found 1 failure on this sample. You can find the script [1], the pcapng file [2] and the logfile [3] in this message.

The script uses Scapy [4] to read the packets from the pcapng file as well as sending them, which unfortunately requires sudo to send packets in the network. Although sudo for this is ugly (imho), you can still easily inspect the very small and simple script.

Please let us know if you were able to reproduce it and/or if further support is needed for that.

[1] http://www.students.ic.unicamp.br/~ra163122/71125fc10d5015103de58f3b2781a0ea3c8c4cc0d489bcb1f585a762a1eff220.py [2] http://www.students.ic.unicamp.br/~ra163122/71125fc10d5015103de58f3b2781a0ea3c8c4cc0d489bcb1f585a762a1eff220.pcapng [3] http://www.students.ic.unicamp.br/~ra163122/71125fc10d5015103de58f3b2781a0ea3c8c4cc0d489bcb1f585a762a1eff220.log [4] https://github.com/secdev/scapy/

[dubek]

Thank you, I will look into this in the upcoming days.

How did you notice this is a failure (or possible security vulnerability)? What was the outcome of processing this traffic with crosscoap?

[bsmelo]

NP, please let me know if you find the cause and fix it.

You can see the outcome in [3], the logfile: crosscoap segfaults due to invalid memory address or nil pointer dereference.

[dubek]

I found the issue and fixed it in 26de9d16f99913f308c174a2da5328960b9f2d61 . A simple CoAP packet with URI-Path set to % reproduced the issue (see the test case added in that commit).

The problem was a null-pointer dereference, so it indeed crashes the server but I don't think could cause memory leakage or remote code execution. Nevertheless, that you for finding and reporting the issue. Your detailed report allowed me to find the problem quickly.