There is supposedly a major disclosure coming for "all GNU/Linux systems" from Simone Margaritelli: https://threadreaderapp.com/thread/1838169889330135132.html
1,000
1.00Patches are publicly available now and seem to have landed in Debian stable. I haven't checked if there's patches for all of the CVEs, but the linked patches on their own should be enough to disrupt the exploit chain that enables the RCE, so I think the patches questions can all resolve Yes now.
@wasabipesto `foomatic-rip` was already vulnerable as of 2011, as the disclosure article describes, with there even being CVEs for it but the fix not being ported to CUPS.
Two more parts of this exploit chain, CVE-2024-47076 and CVE-2024-47175, are for libraries not performing validation. I'd be shocked if they somehow had validation 10 years ago and then removed it - that's not how software development works.
The final part is cups-browsed listening on all interfaces. The code binding to 0.0.0.0 described in the article is indeed present 10 years ago and is completely unchanged. That takes care of CVE-2024-47176.
It seems that the entire exploit chain has been present for over a decade. Is that sufficient for a YES resolution?
They also disclosed a stack buffer overflow unrelated to the main exploit chain, which is likely an RCE on its own. I checked Git history - here's the current buggy version, and here's that code 10 years ago. Only one of the two loops is present, but both are vulnerable in the same way, so having even one is sufficient for a vulnerability. Even if the exploit chain somehow doesn't qualify as decade-old, this ought to.
@SergeyDavidoff I was a bit unclear on the "decade" question when I looked at the code. Could we hold off on resolving it until tomorrow? I'd like to take a look again and will report what I've found.
@wasabipesto @SergeyDavidoff Ok, I think I've found a piece of the exploit chain that was only added in 2015. So I think I'm ready to argue that the "decade" question is a No based on its narrow resolution criteria.
Of the four CVEs that form the exploit the chain, the second one (CVE-2024-47076) is where CUPS downloads a remote PPD, and then passes it on without adequate validation. The line in question that does the downloading is: p->prattrs = cfGetPrinterAttributes(p->uri, NULL, 0, NULL, 0, 1);
If we go back through the commit history, this line was previously: p->prattrs = get_printer_attributes(p->uri, NULL, 0, NULL, 0, 1);
Going back further, the get_printer_attributes function in turn was added in this commit, which extracts the network code from inline code into get_printer_attributes. The network code that was inline in its place is: uri_status = httpSeparateURI(...).
This code in turn was first added in 2013 in this commit (scroll to utils/cups-browsed.c, click Load Diff, and Ctrl+F for uri_status = httpSeparateURI). But you'll notice that the previous line is #if 0. So this code is only work-in-progress code, and not actually compiled.
Which brings us to this commit, which was only added in 2015, titled "cups-browsed: Added PPD file generator for auto-setup of IPP printers." where the download code is enabled by removing the #if 0. (Ctrl+F for uri_status = httpSeparateURI to go to the relevant part of the diff.)
--------------
They also disclosed a stack buffer overflow unrelated to the main exploit chain, which is likely an RCE on its own.
I completely agree that this is likely an RCE, but evilsocket hasn't actually shown it to be an RCE, which means there's still the possibility that it's a crash that can't be turned into an RCE.
To me CUPS looks like a pinata of vulnerabilities, and you'd get plenty more RCEs if you so much at poke at it -- whether it's from the stack overflow, by finding another variant of the exploit chain, or somewhere else in the code. But the resolution criteria here require that the RCE disclosed by evilsocket, with only the information provided in the disclosure, is enough to execute the attack 10 years ago. And to me it looks like this particular exploit chain wasn't possible 10 years ago.
--------------
Finally, there's the question whether there might be more disclosures coming -- evilsocket is hinting at a part 2 and 3 in his blog post -- and there's the possibility that those are Linux RCEs. I'll leave it to @wasabipesto to decide how this should resolve if this RCE wasn't present a decade ago, but another, different RCE was.
@yetforever Thanks for the well-researched response! I will have to investigate this to confirm but does seem like this particular chain would not be eligible for the decade question.
Should we set a deadline for the "reasonable timeframe" to disclose the remaining vulnerabilities?
@yetforever Thank you for the detailed analysis!
But the resolution criteria here require that the RCE disclosed by evilsocket, with only the information provided in the disclosure, is enough to execute the attack 10 years ago.
I didn't expect the resolution criteria to be about this single RCE chain when betting based on the clarification requested in the comments:
Do the "major incident" and "over a decade" questions include any other vulns that are later disclosed in the same batch? That is, same researcher and CUPS within a reasonable timeframe?
To which the question's creator replied:
Yes, any of these vulnerabilities will count.
I was trading on the assumption that the memory corruption bug reported in the very same post would also count - or at least that's how that clarification read to me. That's why I've placed such a big bet.
It is also possible that we'll never really know if that particular memory corruption issue is can be exploited to get RCE or not, since proving it one way or another requires a non-trivial amount of work from people with very specific and in-demand skills, which makes such analysis very costly.
@SergeyDavidoff I apologize for any confusion here, but in that comment I noted my intention:
Basically if you sent this information back 10 years could you reasonably reproduce the RCE.
I would potentially count the memory corruption issue for these questions if an RCE path utilizing that issue is described in an upcoming post, otherwise as you point out it would take a non-trivial amount of work to develop such an exploit.
@yetforever I think 6 weeks from the first post would be sufficient, which would put it at 11/7. Let's plan to use that as our cutoff.
Of the four CVEs listed in the evilsocket disclosure post, the first three are 8.x, and the last one is 9.x:
https://www.cve.org/CVERecord?id=CVE-2024-47176
https://www.cve.org/CVERecord?id=CVE-2024-47076
There seem to be multiple vulnerabilities. I also haven't check yet which of those are RCEs. For this question to resolve yes, does it require
some or all to have been there for over a decade?
And do those vulns have to be RCEs specifically?
@yetforever Good question. I am looking for any path to RCE using the identified methods (or their equivalents) over a decade ago. Basically if you sent this information back 10 years could you reasonably reproduce the RCE. If the code changed significantly but the underlying behavior was still present that would count.