Patch Madness: Vendor Bug Advisories Are Broken, So Broken

BLACK HAT USA – Las Vegas – Keeping up with security-vulnerability patching is challenging at best, but prioritizing which bugs to focus on has become more difficult than ever before, thanks to context-lacking CVSS scores, muddy vendor advisories, and incomplete fixes that leave admins with a false sense of security.

 

That’s the argument that Brian Gorenc and Dustin Childs, both with Trend Micro’s Zero Day Initiative (ZDI), made from the stage of Black Hat USA during their session, “Calculating Risk in the Era of Obscurity: Reading Between the Lines of Security Advisories.”

 

ZDI has disclosed more than 10,000 vulnerabilities to vendors across the industry since 2005. Over the course of that time, ZDI communications manager Childs said that he’s noticed a disturbing trend, which is a decrease in patch quality and reduction of communications surrounding security updates.

 

“The real problem arises when vendors release faulty patches, or inaccurate and incomplete information about those patches that can cause enterprises to miscalculate their risk,” he noted. “Faulty patches can also be a boon to exploit writers, as ‘n-days’ are much easier to use than zero-days.”

 

The Trouble With CVSS Scores & Patching Priority

 

Most cybersecurity teams are understaffed and under pressure, and the mantra “always keep all software versions up-to-date” doesn’t always make sense for departments who simply don’t have the resources to cover the waterfront. That’s why prioritizing which patches to apply according to their severity rating in the Common Vulnerability Severity Scale (CVSS) has become a fallback for many admins.

 

Childs noted, however, that this approach is deeply flawed, and can lead to resources being spent on bugs that are unlikely to ever be exploited. That’s because there’s a host of critical information that the CVSS score doesn’t provide.

 

“All too often, enterprises look no further than the CVSS base core to determine patching priority,” he said. “But the CVSS doesn’t really look at exploitability, or whether a vulnerability is likely to be used in the wild. The CVSS doesn’t tell you if the if the bug exists in 15 systems or in 15 million systems. And it doesn’t say whether or not it’s in publicly accessible servers.”

 

He added, “And most importantly, it doesn’t say whether or not the bug is present in a system that’s critical to your specific enterprise.”

 

Thus, even though a bug might carry a critical rating of 10 out of 10 on the CVSS scale, it’s true impact may be much less concerning than that critical label would indicate.

 

“An unauthenticated remote code execution (RCE) bug in an email server like Microsoft Exchange is going to generate a lot of interest from exploit writers,” he said. “An unauthenticated RCE bug in an email server like Squirrel Mail is probably not going to generate as much attention.”

 

To fill in the contextual gaps, security teams often turn to vendor advisories – which, Childs noted, have their own glaring problem: They often practice security through obscurity.

 

Microsoft Patch Tuesday Advisories Lack Details

 

In 2021, Microsoft made the decision to remove executive summaries

from security update guides, instead informing users that CVSS scores would be sufficient for prioritization – a change that Childs blasted.

 

“The change removes the context that’s needed to determine risk,” he said. “For example, does an information-disclosure bug dump random memory or PII? Or for a security-feature bypass, what is being bypassed? The information in these writeups is inconsistent and of varying quality, despite near universal criticism of the change.”

 

In addition to Microsoft either “removing or obscuring information in updates that used to produce clear guidance,” it’s also now more difficult to determine basic Patch Tuesday information, such as how many bugs are patched each month.

 

“Now you have to count yourself, and it’s actually one of the hardest things I do,” Childs noted.

 

Also, the information about how many vulnerabilities are under active attack or publicly known is still available, but buried in the bulletins now.

 

“As an example, with 121 CVEs being patched this month, it’s kind of hard to dig through all of them to look for which ones are under active attack,” Childs said. “Instead, people now rely on other sources of information like blogs and press articles, rather than what should be authoritative information from the vendor to help determine risk.”

 

It should be noted that Microsoft has doubled down on the change. In a conversation with Dark Reading at Black Hat USA, the corporate vice president of Microsoft’s Security Response Center, Aanchal Gupta, said the company has consciously decided to limit the information it provides initially with its CVEs to protect users. While Microsoft CVEs provide information on the severity of the bug, and the likelihood of it being exploited (and whether it is being actively exploited), the company will be judicious about how it releases vulnerability exploit information, she said.

 

The goal is to give security administrations enough time to apply the patch without jeopardizing them, Gupta said. “If, in our CVE, we provided all the details of how vulnerabilities can be exploited, we will be zero-daying our customers,” she said.

 

Other Vendors Practice Obscurity

 

Microsoft is hardly alone in providing scant details in bug disclosures. Childs said that many vendors don’t provide CVEs at all when they release an update.

 

“They just say the update fixes several security issues,” he explained. “How many? What’s the severity? What’s the exploitability? We even had a vendor recently say to us specifically, we do not publish public advisories on security issues. That’s a bold move.”

 

In addition, some vendors put advisories behind paywalls or support contracts, further obscuring their risk. Or, they combine multiple bug reports into a single CVE, despite the common perception that a CVE represents a single unique vulnerability.

 

“This leads to possibly skewing your risk calculation,” he said. “For instance, if you look at buying a product, and you see 10 CVEs that have been patched in a certain amount of time, you may come up with one conclusion of the risk from this new product. However, if you knew those 10 CVEs were based on 100+ bug reports, you might come to a different conclusion.”

 

Placebo Patches Plague Prioritization

 

Beyond the disclosure problem, security teams also face troubles with the patches themselves. “Placebo patches,” which are “fixes” that actually make no effective code changes, are not uncommon, according to Childs.

 

“So that bug is still there and exploitable to threat actors, except now they’ve been informed of it,” he said. “There are many reasons why this could happen, but it does happen – bugs so nice we patch them twice.”

 

There are also often patches that are incomplete; in fact, in the ZDI program, a full 10% to 20% of the bugs researchers analyze are the direct result of a faulty or incomplete patch.

 

Childs used the example of an integer overflow issue in Adobe Reader leading to undersized heap allocation, which results in a buffer overflow when too much data is written to it.

 

“We expected Adobe to make the fix by setting any value over a certain point to be bad,” Childs said. “But that’s not what we saw, and within 60 minutes of the rollout, there was a patch bypass and they had to patch again. Reruns aren’t just for TV shows.”

 

How to Combat Patch Prioritization Woes

 

Ultimately when it comes to patch prioritization, effective patch management and risk calculation boils down to identifying high-value software targets within the organization as well as using third-party sources to narrow down which patches would be the most important for any given environment, the researchers noted.

 

However, the issue of post-disclosure nimbleness is another key area for organizations to focus on.

 

According to Gorenc, senior director at ZDI, cybercriminals waste no time integrating vulns with large attack surfaces into their ransomware tool sets or their exploit kits, looking to weaponize newly disclosed flaws before companies have time to patch. These so-called n-day bugs are catnip to attackers, who on average can reverse-engineer a bug in as little as 48 hours.

 

“For the most part, the offensive community is using n-day vulnerabilities that have public patches available,” Gorenc said. “It’s important for us to understand at disclosure if a bug is actually going to be weaponized, but most vendors do not provide information regarding exploitability.”

 

Thus, enterprise risk assessments need to be dynamic enough to change post-disclosure, and security teams should monitor threat intelligence sources to understand when a bug is integrated into an exploit kit or ransomware, or when an exploit is released online.

 

Ancillary to that, an important timeline for enterprises to consider is how long it takes to actually roll out a patch across the organization, and whether there are emergency resources that can be brought to bear if necessary.

 

“When changes occur to the threat landscape (patch revisions, public proof-of-concepts, and exploit releases), enterprises should be shifting their resources to meet the need the need and combat the latest risks,” Gorenc explained. “Not just the latest publicized and named vulnerability. Observe what’s going on in the threat landscape, orient your resources, and decide when to act.”

 

Full article attribution is made to its original source and author.