Analyzing SonicWall’s Unsuccessful Fix for CVE-2020-5135

Image

Back in September 2020, I configured a SonicWall network security appliance to act as a VPN gateway between physical devices in my home lab and cloud resources on my Azure account. As I usually do with new devices on my network, I did some cursory security analysis of the product and it didn’t take long before I had identified what looked like a buffer overflow in response to an unauthenticated HTTP request. I quickly reported the issue to SonicWall’s PSIRT on September 18 and received a same day response that my report was a duplicate of another report they had received. When the advisory was ultimately published, I learned that the other report was one out of 11 from Nikita Abramov with Positive Technologies. In this post, I will discuss some aspects of the vulnerabilities I found, my interactions with SonicWall PSIRT, and some general thoughts about vulnerability handling and disclosure.

Reviewing CVE-2020-5135 Vulnerability

I continued to research the issue I’d found and confirmed that it was in fact a stack-based buffer overflow and that the issue could likely be exploited to run code on the vulnerable SonicWall products. My analysis of the flaw indicated that an unbounded string copy was being used to copy data from an HTTP request header directly into a response buffer and without an appropriate length check. On September 22, I wrote again to SonicWall PSIRT to ask for confirmation regarding the CVSS scoring of the issue and for an estimate of when the patch would be released. After a week without a response, I sent a follow-up email and the team responded quickly this time to offer October 5 as a patch ETA but indicated that they did not have a CVSS score calculated.

When October 5 came, there was no vulnerability advisory being published and I still had not heard a CVSS or CVE for the issue, so I reached out again to their PSIRT who this time replied that the release had been postponed until October 14^th now due to a delay in QA. The email also included a CVSS vector string ‘AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H’ which notably lacks any impact of confidentiality or integrity, which is odd for a stack-based buffer overflow. I shared with them some debug logs showing that I could control values on the stack suggesting that this is more than a simple DoS vulnerability.

Discovery of a Memory Dump

Later that same day, I decided to spin up a SonicWall instance on Azure to confirm how it responded to my proof-of-concept exploit. In the past, when researching network appliances, I have observed differences in vulnerable behavior between virtual and physical systems. In some past research, I have observed differences in vulnerable behavior related to hardware-based acceleration utilizing a separate code path.  In this case, I was surprised to find that, rather than a system crash, my exploit payload instead triggered a flood of binary data in the response.

Image

As you can see from the screenshot, there are values in the binary data which certainly look like they could be memory addresses. Although I never observed recognizable text in the leaked memory, I believe this output could vary based on how the target system is used. I also suspect that the values in my output are in fact memory addresses which could be a useful information leak for exploiting an RCE bug. I reported this to SonicWall PSIRT on a Tuesday (October 6) but when I hadn’t heard by Friday, I sent a follow-up explaining my analysis of the flaw and asking for clarification on why this platform behaves differently. My assessment was that the CVE-2020-5135 fix was botched. The unbounded string copy was replaced with an appropriate memory safe function, but the return value was not properly considered. It’s not the first time I’ve encountered this general issue. Functions like snprintf return the number of bytes which would have been copied if the copy were not truncated. If this return value is used as a length for a network send, the application can end up writing data from adjacent memory onto the network.

Vendor Confirmation

On October 9, SonicWall confirmed my expectation that this was the result of an improper fix for CVE-2020-5135 and told me that the patched firmware versions had already started to become available on mysonicwall.com as well as via Azure. Six days after I had initially reported the botched fix, SonicWall emailed me with a link to the now published advisory and added that they’d let me know when the memory dump issue is resolved and ready for release. As a one- or two-line fix with minimal impact, I had expected that a patch would probably come out quickly but, fast-forward to March and I still had not heard back. I reconnected with their PSIRT on March 1, 2021 for an update, but ultimately it took until well into June before an advisory could be released.

This and other fixes are now available in the following firmware releases from SonicWall:

FIXED SOFTWARE