Thoughts from the disclosure process of a cryptographic vulnerability (CVE-2018-8319)
A few months ago, I had the privilege of reporting a few bugs in the Microsoft Research JavaScript cryptographic library (msrCrypto), and I chose to go through Microsoft's Security Response Center. As these weren't XSS, RCE, etc., bugs -- but instead weaknesses exposed in cryptographic primitives inside a library -- it wasn't your "standard" report by any means. I decided I'd share my thoughts on the process and why it can sometimes be challenging.
This report became CVE-2018-8319, and I won't go into the specific bugs here. You can read in detail about them here to understand all the math, if you so choose. Huge credit goes to Jonathan Burns and Colin McRae (colleagues at Ionic Security) for their work on the issues, including extensive testing and debugging around them.
Typically, I share the vulnerabilities I find directly with vendors or others through pre-established relationships -- i.e., not going in the "front door" of the vulnerability reporting email, or similar. There are a number of reasons for that, but that's not the focus of this post -- let's discuss this specific case.
When I originally contacted MSRC with an overview of the issue, I received what looked like a form letter asking me for things including a "short explanation on how an attacker could use the information to exploit another user remotely" and a proof of concept "such as a video recording, crash reports, screenshots, or relevant code samples." Needless to say, a cryptographic vulnerability in a library isn't something which lends itself well to these mediums. Instead, the data I had shared was about where in the computation there were differences from the appropriate elliptic curve math, and that this should be able to lead to an attack that would weaken the keys.
After another reply, in which they explained that this bug needed to be evaluated by their cryptographic team or the development team on this library, they opened a case and assigned a case manager. From this point on, the communication went smoothly as I would expect.
I've seen this process not only from the researcher's side, but also from the vendor's side. My team at River Loop Security and I often help the vendor respond to incoming vulnerability reports about hardware or firmware issues. I know that as a researcher, it's not unusual to get some frustrating replies to initial bug reports, but why is this the case? In my opinion, it comes down to two major reasons:
- Vulnerability report programs are overwhelmed by low-quality bugs, duplicate reports, and/or out-of-scope submissions
- Triage analysts are often relatively junior, and may not be versed in a broad spectrum of attacks
With these points in mind, we can't blame the people triaging reports for their form responses, even when they seem inappropriate for the content that was sent in. Although as a white-hat researcher reporting a bug we're helping the company by "giving them a vulnerability for free," we need to expect that it will be the norm to need a discussion to help them understand the bug -- and convince them of its validity.
At River Loop Security, we've worked with multiple vendors to help them build responses that acknowledge the uniqueness of the hardware or firmware vulnerability, as well as provide resources to reproduce or validate the vulnerability if they do not have the ability in-house. However, for hardware or firmware vulnerabilities especially, we find that it's important to help the researcher submitting the issue understand that these are different from a typical "software" vulnerability report. This involves sharing that these vulnerabilities may take significantly longer to fix if hardware has to be updated, or may be tough to patch if the vendor didn't proactively plan for secure and scalable over-the-air updates.
Just like cryptographic bug reports aren't the bread-and-butter of most vulnerability submission programs, neither are hardware or firmware vulnerabilities. For each of these, the vendor needs to have specialized talent and processes in place to provide the researcher a positive experience.