Uncoordinated Vulnerability Disclosure: The Continuing Issues with CVD

On patch Tuesday last week, Microsoft released an update for CVE-2024-38112, which they said was being exploited in the wild. We at the Trend Micro Zero Day Initiative (ZDI) agree with them because that’s what we told them back in May when we detected this exploit in the wild and reported it to Microsoft. However, you may notice that no one from Trend or ZDI was acknowledged by Microsoft. This case has become a microcosm of the problems with coordinated vulnerability disclosure (CVD) as vendors push for coordinated disclosure from researchers but rarely practice any coordination regarding the fix. This lack of transparency from vendors often leaves researchers who practice CVD with more questions than answers.

If you’re just interested in the technical details of the bugs we discovered in the wild, my colleagues Peter and Ali have a fantastic write-up here, which includes IOCs and detection guidance.

What happened to transparency in communication?

We were surprised by the publication of CVE-2024-38112, and we weren’t the only ones. When an In-the-Wild (ITW) exploit goes unpatched for that long a time, it’s not unusual for someone else to independently discover it. In this instance, it was Haifei Li at Check Point who also detected this ITW and reported it to Microsoft. He too was surprised by the patch and noted it wasn’t the first occurrence: 

That doesn’t seem to be the only communication problem from this release. Kẻ soi mói, a researcher from Dataflow Security, expressed his dismay about SharePoint bugs getting fixed that were similar to bugs he had submitted but were as yet unactioned:

His frustration with the disclosure process here is clear. Even when there are no obvious communication issues when reporting a bug, there can be issues when the fix is disclosed. That is what happened with Valentina Palmiotti, a researcher with IBM X-Force. She had a winning entry at Pwn2Own this year, but when the fix was released, despite literally handing Microsoft a working exploit, they made an odd choice in the CVSS rating:

CVD doesn’t work if the only ones coordinating are the researchers. While these are Microsoft examples, there are multiple occasions from various vendors where “coordination” simply means “You tell us everything you know about this bug, and maybe something will happen.”

How can we trust you if you aren’t acting trustworthy?

In the Fall of 2023, Microsoft launched its Secure Future Initiative (SFI). Many in the security community – me included – hoped this would be like the TwC memo from Bill Gates that launched the MSRC and would result in a new age of security and transparency from the Redmond giant. Sadly, that has failed to materialize.

In May of this year, they updated their SFI site with additional information, including a whitepaper entitled, Setting a new standard for faster vulnerability response and security updates [PDF]. Interestingly, it included the following graphic defining the vulnerability lifecycle at Microsoft.

As a former Microsoft employee, I recognize this graphic as it was something similar to one I saw while there. At the bottom there is “Partner with Researcher”, which implies that open communications happen throughout the process, however, that clearly isn’t happening.

Vendors want researchers to trust them, but they aren’t taking the necessary steps to earn our trust. What’s sad is that we aren’t asking for a lot. Tell us you’ve received the report. Confirm or deny our findings. Tell us when a patch is coming. Acknowledge us appropriately (and spell our name right). And finally, once the patch is available, tell us where we can find the patch. Strangely, one of the biggest problems we have at the ZDI is just getting vendors to tell us when something is fixed.

Who arbitrates disagreements?

Here at the ZDI, one of the best things we offer researchers who sell bugs to us is that we handle the communications with the vendors. What happens when the vendor states the fix should be a defense-in-depth update rather than a full CVE? What happens when the vendor states the impact is spoofing but the bug results in remote code execution? If you’re a lone researcher, your voice might not be heard. The ZDI has existed since 2005, so we have a lot of experience in disclosing bugs and understand how to argue on behalf of the researcher.

There are times when even the ZDI is often not heard when these disagreements are had. However, we have the advantage of blogging platforms, social media, PR agencies, and legal teams backing us up. The average researcher typically doesn’t have access to such resources. The option to just 0-day the bug and release everything publicly becomes quite attractive. It’s not just about disagreements – it’s about network defenders and end users not having the right information to estimate the risk to their enterprises.

Let’s take CVSS ratings as an example. In the last patch Tuesday, Microsoft rated a RADIUS vulnerability as CVSS 7.5, but the researcher who discovered the bug rated it as a 9.0. Not only does that change the severity level from High to Critical, but it could also change how quickly a patch is deployed. Maybe your enterprise rolls out Critical-rated patches in 30 days but allows up to 90 for High severity bugs. A simple disagreement could result in a drastically different security posture for millions of people. In one sense, the CVE program was supposed to solve this problem. There exists a methodology for disputing CVEs [PDF], but this dispute process has not proved effective.

Other than bounties, why would researchers report bugs to vendors who don’t coordinate?

If you don’t offer a bounty payout and don’t coordinate with researchers or properly credit them, why in the world would anyone report bugs to you? Let’s say you’ve had a bad experience with a vendor. For most, they stop reporting bugs to that vendor. It’s not worth their time or effort. And I totally understand that feeling. However, that doesn’t mean that bugs in that vendor’s product simply disappear. Threat actors don’t care if a vendor is difficult to work with; they just keep exploiting the bugs until they can’t.

If researchers are actually worried about exploitation but don’t want to deal with the vendor, what’s stopping them from just dropping 0-day? That way, they know they will be credited, and the vendors typically move fast on publicly known bugs. Of course, vendors say that would be irresponsible of the researchers. And the researchers think it’s irresponsible for multi-billion dollar corporations to release shoddy code. That’s where the idea of “coordinated disclosure” came from. It took the good ideas of “responsible disclosure” and removed the moral judgments. CVD was also meant to acknowledge the vendor has a responsibility to the researcher. This is the part of the CVD process that needs the most improvement. Researchers have responded by doing their part; now it’s time to have the vendors step up and do theirs.

Quis custodiet ipsos custodes?

In April of 2024, the Cyber Safety Review Board (CSRB) released a report on Microsoft’s response to the Exchange Online intrusion from 2023. As a result of that report and the recommendations laid out in it, Microsoft president Brad Smith testified before Congress concerning the ongoing security improvements at Microsoft. Interestingly, on the same day, an article from ProPublica detailed how Microsoft ignored warnings from one of their engineers about a problem that led to the SolarWinds compromise.

While it’s good to see some official accountability somewhere, we as an industry must hold each other accountable for open and transparent communications as well. That’s one of the reasons the ZDI will be launching the Vanguard Awards at this year’s Black Hat. These awards are designed to highlight the best of both researchers and vendors. There won’t be a “failure” category because we’d rather reward outstanding work rather than highlight mistakes or miscalculations. We’ll be presenting vendor awards in five categories:

-              Best Security Advisories
-              Most Transparent Communication
-              Most Collaborative
-              Most Improved
-              Fastest to Patch

The winners of some of these will likely turn some heads, but it’s our way of monitoring and rewarding those in the industry who go above and beyond to make CVD work for everyone.

Conclusion 

Why is CVD not working? Have the number of bugs being disclosed increased to the level where vendors simply cannot cope with the level of coordination? Have budget cuts reduced the number of response personnel vendors employ? Has the rush to automation come at the expense of coordination? Are researchers just reporting to an API and no humans are reviewing the reports? As I said, we’re left with more questions than answers.

The lack of coordination doesn’t just hurt the vendor/researcher relationship. It hurts the end users. It lowers their ability to gauge risk, and it lowers their trust in security patches as well. Hopefully, increased government scrutiny and industry programs like the Vanguard Awards will serve as a stick-and-carrot approach that results in positive changes. It is said that security is a journey rather than a destination. Improvement works the same way. We can always get better, but we have to agree that we need to.

You can find me on Twitter at @dustin_childs and on Mastodon at @TheDustinChilds, and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.