No smoke without fire? ‘Critical’ Loguru security flaw turns out to be non-issue

Invalid CVE saga highlights potential problems in the automated vulnerability alert process

GitHub has promised to stop sending out advisories about a vulnerability reported in Loguru, a popular Python logging package, which later turned out to be invalid.

Last week, the DevOps platform started notifying tens of thousands of users about what was claimed to be a critical remote code execution (RCE) vulnerability in Loguru that was designated as CVE-2022-0329 and given a critical rating of 9.8/10.

However, it has since emerged that the reported issue isn’t a valid vulnerability after all.

The story began when a researcher reported untrusted loading of data by Loguru’s pickle.load function – which serializes and deserializes arbitrary Python objects – leading to arbitrary code execution. He suggested that the issue had similarities to the notorious Log4Shell exploit.

However, the maintainer disputed this on the grounds that the offending method did not form part of the Loguru public API, and that Pickle was only used to serialize objects already loaded in the code – meaning that there was only a problem if the loaded data didn’t come from a trusted source.

“The user receiving untrusted data should be responsible for sanitizing it before processing it. We can’t expect this job to be done by the third-party library, otherwise there might be infinite way to execute arbitrary code,” they said.

“This has little to do with the pickle module. Loguru isn’t fetching and executing arbitrary code by itself.”

However, after a lengthy discussion, the maintainer was pressured into action. A CVE was issued and found its way to GitHub, which then started sending out automatic alerts via its Dependabot service.

Offering further insight, Justin Hutchings, director of product management at GitHub, told The Daily Swig: “CVE-2022-0329 was issued by huntr.dev with a severity of 3.8 (low).

“The National Vulnerability Database (NVD) upgraded the severity score to 9.8 (critical) when they published it, and we subsequently republished it to our Advisory Database and started sending alerts.

“This is a standard practice among all major security vendors, but in this case, the NVD’s reclassification of this as a critical vulnerability caused undue alarm.”

Undeserved credence

Now, though, GitHub has reviewed the issue, and says it will stop sending out the warnings.

“We don’t currently have a way to retract the Dependabot alerts we’ve already sent, but I’ve asked the team to look into functionality to do that in future,” Hutchings said.

“I’ve also asked them to look into adding a clear way to display CVEs in the GitHub Advisory Database that we have chosen not to alert on (even if they have not been withdrawn from the National Vulnerability Database).”

The issue highlights just how easy it can be for a false or disputed report to be given undeserved credence, and Hutchings says he plans to involve the GitHub Security Lab in finding solutions.

“I’d like us (GitHub) to learn from the above and improve our security-related features and processes to help more when a maintainer receives a security report,” he says.

This article has been updated to include additional comments from John Hutchings.

YOU MIGHT ALSO LIKE Xerox belatedly addresses web-based printer bricking threat