CVE-2022-0329 and the problems with automated vulnerability management

Update: Github have responded and said they will stop sending notifications about this CVE.

Yesterday Github started notifying tens of thousands of people about a critical remote code execution vulnerability in a package named loguru. Their reviewed advisory is here. It references CVE-2022-0329 which was published on the 21st of January 2022 with a critical rating of 9.8/10.

The thing is that this vulnerability doesn’t exist. Here is the complete and unedited exploit code as reported to the project and on the huntr bug bounty platform:

import os
import pickle
#os.system('pip install loguru')
from loguru import _recattrs
#payload formation
class ArbitraryCode:
    def __reduce__(self):
        cmd = ('xcalc')
        return os.system, (cmd,)
dumps = pickle.dumps(ArbitraryCode())
_recattrs.RecordException._from_pickled_value(dumps,dumps,dumps)

This code, to put it politely, is complete nonsense. Pickle is a way of serializing and deserializing arbitrary Python objects, and deserializing untrusted pickle data is indeed a security issue. But the exploit code doesn’t show this and there are no code paths in the library that will pass user-supplied
data to pickle. What it’s really reporting is this:

If you write a malicious class and then call an internal library function that happens to call pickle, pickle will call a function in your malicious class.

This is a classic case of “being behind the airtight hatchway”. This reminded me so much of a great post by Raymond Chen entitled “Not even making it to the airtight hatchway: Execution even before you get there” where Microsoft received a security report that boiled down to a user running system("calc.exe") and summarizing that this constituted a security issue.

Basically: if you’re in a position to be able to create malicious objects with arbitrary code inside a system then that system has much bigger problems. So this equivalent code snippet isn’t a security issue that needs to be reported to Python:

class ArbitraryCode:
    def __len__(self):
        os.system('xcalc')

len(ArbitraryCode())

The fix is to just not do that, and if you do then it’s nobodies problem but your own.

The problem is that this security issue, despite not existing, does exist. It’s got a CVE assigned to it at one of the highest ratings possible, people are being notified, patches are being rolled out. Bots are tweeting about it:

As far as I can gather the maintainer was pressured into merging something despite completely valid objections and a rather heated discussion, which resulted in the huntr report being closed. Some automated processes kicked in and a CVE was issued, which made its way into the Github advisory database with a rather weak “The maintainer disputes the issue” comment in the description.

Automated vulnerability systems like Github advisories and Snyk are great steps forward. But as bug bounty programs proliferate so do the number of useless + spammy reports, as anyone who has run such a program will attest. If we build a system where these reports can, accidentally or maliciously, make their way into the Official List Of All Security Issues That You Must Take Action On For Complaince Reasons with no human oversight then we’re in for a bad time.