Critics are accusing major tech companies of not sticking to the rules when it comes to registering vulnerabilities with the appropriate authorities.
Both Juniper Networks and Ivanti have attracted criticism from members of the infosec industry for the way they’ve handled the disclosure of vulnerabilities over the past week.
The networking giant was accused of patching security flaws without disclosing them as standalone vulnerabilities, while Ivanti was called out for seemingly bundling multiple vulnerabilities under a single registered Common Vulnerabilities and Exposures (CVE) ID.
Security vulnerabilities that are serious enough to require patching to avoid problems for organizations generally need to be registered with a CVE Numbering Authority (CNA) and added to the CVE program.
Once registered with a CVE ID, vulnerabilities can be more easily identified and tracked by organizations, making their patching routine more easily manageable.
Aliz Hammond, researcher at watchTowr, reported a number of security issues to Juniper in late 2023. The vendor investigated them and asked Hammond to delay disclosing the details beyond watchTowr’s typical 90-day window so fixes could be published first, during its January quarterly batch of updates.
Hammond claims he had found four vulnerabilities included in Juniper’s latest batch of patches that didn’t appear to have received CVE IDs, including a missing authentication vulnerability – which he described as “often the easiest vulnerabilities to exploit.”
He also drew attention to Juniper’s decision not to issue an out-of-cycle patch, despite the vendor nonetheless deeming the bug serious enough to request a delay to the disclosure window.
“Juniper usually publishes advisories on the second Wednesday of the first month of every quarter, which seems a strange schedule given how urgent security updates tend to be,” Hammond wrote. “We’ve often stated that a vendor’s response to vulnerabilities such as these can be critical in closing their client’s ‘window of vulnerability.’
“Given this, it is interesting that Juniper did not find at least the missing authentication vulnerability to be severe enough to justify an out-of-cycle advisory, nor to register CVE or mention them in the release notes (although they did deem them important enough to request we delay our usual and industry-aligned 90-day VDP timeline).”
The Register contacted Juniper Networks for a response but the company is yet to respond.
VPN vexations
Ivanti’s disclosure practices were similarly criticized by infosec experts discussing the findings on Mastodon.
A researcher looking into the exploited zero-days said they’d discovered that for CVE-2024-21887, which leads to remote code execution (RCE), they could find at least five different command injection vulnerabilities under a single registered CVE ID. Security expert Kevin Beaumont called the practice “a bit naughty.”
According to section 7.2 of the CNA’s rules, the authority clearly sets out its expectations of vendors when reporting vulnerabilities.
“The CVE Program expects separate CVE IDs to be assigned to independently fixable vulnerabilities. If one vulnerability can be fixed without fixing the other, then the vulnerabilities should receive separate CVE IDs.”
The only exception to this rule is when the independently fixable vulnerabilities affect different products that share the same code, or the vulnerable products are impacted because they use the functionality of another product.
The discussion thread ended with the original researcher, Rich Warren, claiming each vulnerability would require individual fixes, and according to the aforementioned rules, this would necessitate separate CVEs.
Ivanti responded to us saying otherwise, though. The vendor said there were multiple vulnerabilities listed under the same CVE, as did Warren, but these vulnerabilities will all be addressed by the same fix.
“At Ivanti our customers’ security is our top priority. Our goal is to communicate clearly and ensure our customers know what actions they need to take,” it told The Register.
“In this instance, to avoid confusion, we chose not to have multiple CVE numbers reserved for vulnerabilities with the same description, same CVSS score, and same fix in the same part of the code.
“Instead, the CVE description noted that there were multiple vulnerabilities in that section of the code. These vulnerable endpoints are all successfully blocked by the mitigation and will all be resolved in the patches that we are releasing soon.”
The vulnerabilities may be independently fixable as Warren said, but Ivanti’s statement suggests that they are all also fixable by a single patch, which will be applied to all of them, meaning the single-CVE approach may just about be within the rules here.
In any case, the same expectations regarding CVE allocations also apply to Juniper Networks – a network security vendor. As for why no CVEs were assigned at all, it’s not clear at this time.
The four vulnerabilities highlighted by Hammond, for example, are currently tracked by Juniper’s own ID system, with details behind a paid customer knowledgebase article.
Despite Juniper being a CNA itself, it’s possible that delaying the assignment of CVE IDs is being done to allow customers time to learn about and patch the issues before information is publicly disclosed, along with a CVE.
Plus, while not disclosing individual vulnerabilities is against industry best practice, Juniper did fix them and offer patches for customers in line with its typical schedule, so there’s no flagrant abuse of the rules and expectations here.
Adam Pilton, cybersecurity consultant at CyberSmart, told us that while there’s no time limit on assigning CVEs, it’s good practice to get them registered as soon as possible to ensure they’re addressed in a timely fashion.
In reference to Juniper’s case, he said: “We must take into consideration that we do not know all the facts, even if on the surface it appears questionable.
“Delaying reporting can be necessary to allow a fix to be ready to ensure responsible disclosure. This helps protect users by giving them time to apply patches before the vulnerability details become public. It can also avoid panic among users and potential exploitation by malicious actors before a solution is available.
“However, delays in reporting can hinder transparency and may leave users unaware of and exposed to potential risks in their systems.” ®