In its July Patch Tuesday updates, Microsoft fixed a zero-day flaw, CVE-2024-38112 (7.5 CVSS), in Trident, Microsoft’s proprietary browser engine for Internet Explorer.
Microsoft called the vulnerability a spoofing flaw, while Trend Micro’s Zero Day Initiative (ZDI) team, which claimed credit for discovering the vulnerability, characterized the weakness as a remote execution flaw that deserved a higher severity score.
“They’re saying what we reported was a defense-in-depth fix only, but they won’t tell us what that defense-in-depth fix is,” Dustin Childs, head of threat awareness at ZDI, said then.
However, the disagreement between the vulnerability researcher and the software giant didn’t end there. Microsoft credited a different security researcher, Haifei Li, with finding and reporting the bug.
Childs said that ZDI reported the bug to Microsoft in mid-May and was caught off guard by the July release because they had been expecting Microsoft to release a patch in August. Even Li was caught off guard.
Clashes arise over who reported a vulnerability
Childs, a Microsoft Security Response Center veteran, tells CSO: “We reported it to Microsoft. Unbeknownst to us at that time, a… researcher also found it and reported it to Microsoft. We were unaware that the patch was coming. We were under the impression it would be available in August. And, we were concerned because we weren’t credited.”
More importantly, ZDI believes that Microsoft did not adequately address the problems that it flagged. “We think the fix is actually insufficient and have reported additional cases to Microsoft based on that insufficient patch,” Childs says.
This clash of interpretations surrounding who reported a flaw, when it was discovered, how severe it is, and whether the resulting patch is adequate is typical of the friction that can crop up between security researchers and software vendors in the coordinated vulnerability disclosure process.
Experts say many factors affect the coordinated vulnerability disclosure process, which can confuse CISOs and sometimes leave them clueless about the extent of the vulnerabilities reported.
Misaligned motives and communications
One fundamental problem in the current vulnerability disclosure environment is the misalignment of expectations and miscommunication between security researchers and the vendor organizations that receive vulnerability reports.
“The causes of these problems center on misaligned expectations and miscommunications,” Chris Evans, CISO of HackerOne, tells CSO. “Organizations want to strengthen their security posture with limited resources without placing their brand reputation at risk. Hackers want to improve the security of the broader internet and, for bug bounty programs, be paid fairly and promptly for their work. When these incentives don’t perfectly align, conflict can arise.”
Evans adds, “While there’s growing regulation mandating the disclosure for certain industries and types of vulnerabilities, this remains a challenge that limits how the broader cybersecurity community can understand and learn from a vulnerability to reduce the chances of similar issues happening in the future.”
Regarding freelance bug reporters and small vendors, the problem is sometimes a lack of understanding of what to do. “Sometimes one of the biggest barriers to effective coordinated vulnerability disclosure is simply that folks don’t know what it is,” Caitlin Condon, director of vulnerability intelligence at Rapid7, tells CSO. “They don’t know what they’re supposed to do.”
Vendors often have difficulty figuring out the bug reports they get. “Vendors are often very passive regarding vulnerability disclosure coordination,” Li, an experienced vulnerability researcher, tells CSO. “They request a lot of information from researchers, sometimes more than necessary for reproducing and investigating the issue. This practice consumes a significant amount of researchers’ time.”
Not only do vendors take up the researchers’ time, but they also frequently fail to engage in reciprocal communication. “Vendors rarely offer anything in return,” Li said. “They may ask for extensive details but do not proactively update you about the status of the case or their patching schedule.”
Companies trying to hide their flaws
The elephant in the room regarding misaligned motives and communications between researchers and software vendors is that vendors frequently try to hide or downplay the bugs that researchers feel obligated to make public.
“The root cause is a deep-seated fear and prioritizing reputation over security of users and customers,” Rapid7’s Condon says. “What it comes down to many times is that organizations are afraid to publish vulnerability information because of what it might mean for them legally, reputationally, and financially if their customers leave. Without a concerted effort to normalize vulnerability disclosure to reward and incentivize well-coordinated vulnerability disclosure, we can pick at communication all we want. Still, the root cause is this fear and the conflict that it engenders between researchers and vendors.”
Condon is, however, sympathetic to the vendors’ fears. “They don’t want any information out there because they are understandably concerned about reputational damage. They’re seeing major cyberattacks in the news, CISOs and CEOs dragged in front of Congress or the Senate here in the US, and lawsuits are coming out against them. I don’t blame vendors at all for being scared, and I don’t blame researchers for being frustrated that they are doing this seminal, highly skilled work.”
More concerningly, some organizations buy bugs from researchers only to bury them, leaving the security community unaware of their existence and bypassing the disclosure process altogether. “I know other organizations with bug bounty programs will purchase bugs specifically to fix them silently,” ZDI’s Childs says.
“The agreements they sign for those companies are incredibly restrictive,” he adds. “If you look at certain companies and you’re like, ‘why are there no CVEs affecting that product?’ it’s because the company is buying them and fixing them silently and not doing a CVE for them and not publicly crediting them.”
The upshot of this practice is that “CISOs don’t get an opportunity to make an informed decision about the things they’re putting on their network,” Childs says. “That’s what frustrates me. You have a product where you know vulnerabilities exist, but you research this product and can’t find anything negative about it because they’ve essentially buried it.”
Getting bug reports through can be challenging
Another significant barrier to adequate coordinated vulnerability disclosure is simply reaching the relevant vendor personnel, a difficult task compounded by the fact that communicating with bug reporters might be low on the vendors’ priorities list.
“Getting information back from the vendor about the bug’s status can be challenging,” Childs says. “The vendors are dealing with a huge number of bugs, more than they’ve ever dealt with in the past. What it boils down to is that the researcher is their lowest priority. They have other priorities that they’re working on, whether it be developing a fix or hopefully testing a fix before releasing it, that sort of thing. And the communication just gets dropped.”
Communicating with small vendors can be more of a challenge than dealing with large companies like Apple, Google, Microsoft, or Cisco. “Dealing with smaller providers and niche software things, it can be hard to find where to report the bugs,” Childs says. “We’ve even gone as far as to try to reach out to CISOs and CIOs on LinkedIn to try and report bugs. We’ve sent messages through support sites to try to report bugs. Sometimes, it gets reported to one person, but it’s not the right person.”
“We go to extreme lengths at Rapid7 to try to ensure that that information gets in the right hands however possible,” Condon says. “We have used certified mail, we have used fax, we have called people on the phone, something that tech folks don’t do in the year 2024.”
Researcher disrespect can be an issue
Another hindrance to a smooth, coordinated disclosure process is the level of disrespect that security researchers sometimes experience from vendors, either in the form of inadequate or absent bounty payments or radio silence after submitting their reports.
“If hacker efforts are not recognized or rewarded fairly and consistently, it can lead to conflict and reduced program reputation and engagement for an organization,” Hacker One’s Evans says. “Lack of timely updates and clear communication from organizations about the status of their vulnerability reports leaves hackers in the dark about their findings’ progress and potential resolution.”
Childs says the solo independent researchers bear the brunt of the disrespect vendors show to bug reporters. “If you’re just a researcher out there on your own and this is the first bug reported, you might get blown off by the vendor because they think, ‘this is one little guy, it doesn’t matter.’ The vendor might think, ‘We won’t tell him anything. We’re just going to fix a report and maybe credit him, maybe not, maybe pay him, maybe not.'”
How to make the disclosure process better
Fixing these and other problems in the vulnerability disclosure process requires vendors to make more effort to communicate clearly and establish better disclosure policies.
“Addressing these problems requires organizations and bug bounty companies to prioritize building clear, consistent policies, fair and transparent practices, and a commitment to continuous improvement,” Hacker One’s Evans says.
“One way to build consistent policies is by adopting and adhering to clear platform standards. Standardization provides clearer processes that improve communication, match program operations to disclosure best practices, and align expectations for how the disclosure process will go and how hackers will be paid.”
Investing in qualified security personnel who can field researchers’ reports could also help resolve some problems. “Investing in security responders and people who are good at outreach and notifying the researcher community sends a signal to researchers that they are valued,” ZDI’s Childs says.
Better qualified security personnel can also address the problem of inadequate patches. “Very recently, Adobe attempted to patch a bug in Adobe Reader, but upon reviewing their released patch, I found that the bug was not patched correctly,” Li says. “If we had not tested and released our blog post, users would have been at risk because the bug was not properly patched while details about it were publicly disclosed.”
Like the other experts, Childs emphasizes that another critical step in addressing disclosure process problems is for vendors to make it easier for researchers to report vulnerabilities. “Even if you don’t have a formal piece or you’re not overflowing with engineers, just make it easy to report bugs, and people will work with you.”