Which of the following are true about the September 2024 Linux RCE?
Standard
10
Ṁ8169
Dec 31
36%
At least one major incident attributed to the issue by EOY
20%
The RCE has been there for over a decade
Resolved
YES
Disclosed by 10/8/24
Resolved
YES
Patches are available in any form by 11/1/24
Resolved
YES
Patches are available in Debian stable by 11/1/24
Resolved
YES
Patches are available in Debian stable by EOY

There is supposedly a major disclosure coming for "all GNU/Linux systems" from Simone Margaritelli: https://threadreaderapp.com/thread/1838169889330135132.html

HN Thread: https://news.ycombinator.com/item?id=41628163

Get
Ṁ1,000
and
S1.00
Sort by:

Patches 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 Ping! Am I assuming wrong about how this resolves?

@yetforever Thanks for the ping. I would agree it mitigates the issue, resolved.

sold Ṁ97 The RCE has been the... YES

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?

@yetforever Yes, any of these vulnerabilities will count.

@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.

opened a Ṁ1,500 The RCE has been the... NO at 85% order

@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.

sold Ṁ83 The RCE has been the... NO

@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.

The work I do for mana...

@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.

The RCE has been there for over a decade

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

  1. some or all to have been there for over a decade?

  2. 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.