CVE-2022-0329 and the problems with automated vulnerability management(tomforb.es)
tomforb.es
CVE-2022-0329 and the problems with automated vulnerability management
https://tomforb.es/cve-2022-0329-and-the-problems-with-automated-vulnerability-management/
7 comments
Part of the problem is, vulnerability scans are the only tool for vulnerability management that our puny tiny pathetic programmer brains have invented. Now, realistically, it would make a lot more sense if libraries that call pickle() had some kind of "use warning" attached to them, which your IDE would use to detect when you do something that opens you up to compromise (such as using untrusted user data in some weird contrived context that forces a library to call pickle() on it). But NO. You CANNOT have this. Everything MUST be a CVE.
This is quite hard to do correctly though? I think you're talking about tainting all user inputs and tracing their path through a system, but this is non trivial and quite possibly impossible in the general case.
But the author fixed it? https://github.com/delgan/loguru/commit/4b0070a4f30cbf6d5e12...
Obviously there was something the library could "do better." I think the root of this issue is trying to squeeze absolutely everything into CVSS
Obviously there was something the library could "do better." I think the root of this issue is trying to squeeze absolutely everything into CVSS
That’s not the point - the function wasn’t exploitable and the vulnerability report made no attempt to show that it was exploitable. It showed how to call it.
And yet, we have a CVE.
And yet, we have a CVE.
From what I can tell all this does is move the pickling process to the multiprocessing module, so it 'fixes the problem' by moving the call to pickle into the standard library (so automated code auditing tools or the dude complaining about the usage won't find it) and just removes some (useful) error handling in the process, as well as repeating the pickling process twice. It's entirely an effort to shut up the complaining and doesn't meaningfully change the security of the system at all (which was already fine).
It is plain surprising to see this gets a CVE. What is the next exploit? Calling `system(program)`?
that CVE is invalid, otherwise I suggest to also report the logging core library, as mentionend by the dev, because it does the exactly same use as loguru
I understando folks are on edge because log4shell, but bullying a opensource developer is not the way
python allows the execution of ill-intended code, lets force python to scan code in search of this.... thats who they sound like...
and further proof they are actually bullying him is, someone pickle is "bad", yet the suggested alternative lib says it use pickle in the first paragraph, and this while "threating" to stop using the lib because author "wont fix"...
sometimes I fell ppl forgot how to think....