variable severity CUPS vulnerability

The main event of last week in the field of information security was the discovery of four vulnerabilities in the Common Unix Printing System print service. The vulnerabilities are relevant for many Linux and Unix distributions. Both the vulnerabilities themselves and the method of exploiting them, developed by the discoverer, researcher Simon Margaritelli, are of great interest. However, in addition to the technical features of the problem, last week there was also

drama

with the complexities of the responsible disclosure process, as well as excessive discussion of the personal characteristics of the people involved in the process.

The essence of Margaritelli's research is shown in the screenshot above: in some cases, we can contact the server on which the cups-browsed component is installed and running, and add our own printer without asking. All other vulnerabilities can cause arbitrary code execution. It sounds scary, but for an objective assessment it is better to refer to newsletter Canonical: the problem mainly affects desktop systems and cannot be exploited without user participation. This simple statement has many fine print additions, which we will try to summarize below.

The dry lines of the Canonical newsletter contrast markedly with the emotional report researcher Simon Margaritelli. The path to executing arbitrary code began with scanning open ports on a laptop with a freshly installed Ubuntu OS. This system was found to be keeping UDP port 631 open and was responsible for this being done by a service known as cups-browsed.

It is responsible for automatically detecting and adding printers. Connecting to the port allows you to initiate the addition of a printer externally. In the cups-browsed configuration file, it is possible to impose restrictions on who the system will respond to on a given port, but by default any connections are allowed. All this functionality is an implementation of the protocol Internet Printing Protocol.

Here Simon makes a small digression: he used the fuzzing method and found several cases of cups-browsed crashes during communication on port 631. But he did not investigate the consequences of these data processing errors: perhaps later they will lead to the discovery of other vulnerabilities. The main branch of work used the standard functionality of this subsystem, which made it possible to add a “left printer” to an unsuspecting user of a Linux-based system:

If we return to the screenshot at the beginning of the text, we can note that when calling cups-browsed, system information is also disclosed. At a minimum, the Linux kernel version is known, and in some cases the username may be revealed. This is the first of the vulnerabilities found to receive an identifier CVE-2024-47176: The fact that cups-browsed responds to any request and allows you to randomly add printers to the system is already a problem.

To make matters worse, when adding a printer, a potential attacker controls several lines with its parameters, which are not checked by the attacked system. This is a brief description of two more vulnerabilities in the libcupsfilters and libppd components, respectively. CVE-2024-47076 And CVE-2024-47175. CUPS also includes the cups-filters package, one of the tasks of which is to convert data received for printing into a format “understandable” for the printer. This package contains the executable file foomatic-rip, which also has the problem.

Converters of data from one format to another are traditionally the target of attacks. The foomatic-rip code was no exception. In 2011 it was closed vulnerabilityleading to the execution of arbitrary code if this particular data handler was used when printing. The problem is that this patch has not been ported into the main CUPS code. The vulnerability was not actually closed, and Margaritelli took advantage of it. This is the fourth vulnerability in the attack chain to be identified CVE-2024-47177.

We are gathering an attack. Using “not a bug, but a feature” cups-browsed we add a printer to the system. At this stage we do not require any user action at all, everything happens automatically. At the adding stage, we set the “printer” parameters, including accessing foomatic-rip with arbitrary parameters. These “parameters” (in Simon's example: echo 1 >/tmp/PWNED) will be executed when trying to print anything on a “printer” pre-installed by a potential attacker.

Now let's talk about the accompanying research drama. Margaritelli, being a rather emotional person, was clearly not happy with the process of communication with the CUPS maintainers. Detecting the vulnerability and building the Proof of Concept took two days, while communication with those responsible for the printing subsystem lasted more than three weeks in total (which actually cannot be called something out of the ordinary). As a result, even before the disclosure of information on September 26, there were rumors about some kind of enormous vulnerability in Linux with a CVSS rating of almost 9.9 points out of 10 possible. When in reality it became clear that we were talking about (a) a relatively easy-to-fix problem and (b) a problem affecting a relatively small number of systems, a stage of mild disappointment ensued.

Margaritelli began to be accused of hype on a not so significant issue; he caustically responded to such comments on social networks, attacked the media, accused the developers of delaying the process, and so on. Among all this unconstructive dialogue, there is only one interesting point: where did the vulnerability rating (fourth, in cups-filters and foomatic-rip) of 9.9 points come from? Margaritelli seems to have nothing to do with it, the assessment was suggested in a private correspondence by one of the Red Hat developers. Later it was revised to 9 points exactly.

That is, a private dialogue took place in a closed group, during which someone suggested an assessment of vulnerability. No one was going to publish information until all parties came to a common opinion, so as not to cause unnecessary panic. The problem is that this correspondence was leaked: on September 24, a private discussion of a vulnerability on site American CERT. However, a day earlier, on September 23, the vulnerability assessment was 9.9 points posted to public Margaritelli himself, colorfully describing his frustration at the delay in the responsible disclosure process. The takeaway from this story is that when discussing vulnerability, all parties need to… well, stay calm and exercise restraint. The preliminary discussion in which the danger of a newly discovered problem is assessed should be private precisely in order to prevent unnecessary speculation.

And it so happened that (due to a leak from the CERT VINCE portal) the vulnerability was revealed in its entirety even before the patches were released. Note that the real effect of discovering this vulnerability is still difficult to assess. Perhaps only this particular chain of exploitation is relatively easy to fix, while there may be many other problems within CUPS.

According to independent assessmentOn September 29, more than one hundred thousand systems were found on the network responding to requests on port 631 using the UDP protocol. What kind of systems these are is a question that also remains to be investigated. It’s one thing when these are relatively easily updated desktop computers running Linux (with a white IP), but another thing when we are talking about routers with the CUPS system, which will be updated very slowly or will not receive a patch at all. The relatively good news is that CUPS is not installed by default on server versions of the OS, but there may be some few exceptions to this rule. In any case, we are talking about a fairly serious security hole in Unix-like systems.

What else happened

Last week's equally impressive study published researcher Sam Curry. He and his team found a serious flaw in Kia's web service, which allowed remote door unlocking and engine starting in a large number of the manufacturer's vehicles. To start the attack, all that was required was to know the license plate number of the car.

Kaspersky Lab researchers in detail disassemble Necro Trojan, which was distributed along with a number of applications in the Google Play store.

Windows Recall AI feature returns. We've written about this feature and potential security issues with the data it collects (essentially screenshots every few minutes). After the feature was criticized, Microsoft took a break, and is now ready to implement it again in the near future. With a number of security improvements: access to the “user activity history” will now be possible only if the user’s presence on the computer is confirmed. In addition, Recall can be disabled and even completely removed from the system.

Serious problem (CVSS score 9) closed in the NVIDIA Container Toolkit for virtualization solutions. In a worst-case scenario, the vulnerability allows you to “escape the sandbox” and gain full control over the host.