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.
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 :
🚨 NEW: CVE-2022-0329 🚨 Code Injection in PyPi loguru prior to and including 0.5.3. Severity: CRITICAL https://t.co/trJt2ByLFl— Threat Intel Center (@threatintelctr) January 29, 2022
Severity: 🔥🔥🔥 | Code Injection in PyPi loguru prior to a... | CVE-2022-0329 | Link for more: https://t.co/Vd96bJhjpI— Remotely Alerts (@RemotelyAlerts) January 27, 2022
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.