Critical security flaw in CUPS on GNU/Linux September-October 2024: What you need to know

A quadruple critical security flaw has just been discovered in CUPS for all GNU/Linux systems. This article will be updated with the new information, to provide you with a simple and effective summary of what you need to know and do.

UPDATE 09/29/2024: These flaws only concern CUPS, so very few servers are affected, unless you have printers in your datacenter...! This article has been rewritten accordingly.

A critical flaw: what do we know?

The security researcher Simone Margaritellidiscovered this set of faults in early September.

This concerns CUPS, the Linux printing service. The researcher highlights a possible Remote Code Execution (RCE). without authentication. This means that attackers could potentially execute commands on remote machines without having to identify themselves, making the flaw particularly dangerous. The CVSS score assigned to these vulnerabilities is between 8.3 and 9.0/10 (after being rated at 9.9).

On September 26, Naïm Aouaichia, cybersecurity engineer, alerted us and told us before anyone else that this could affect CUPS :

"Some rumors suggest that this flaw is linked to vulnerabilities in CUPS, the printing service. Yes, your printers may be at the heart of it all. To be confirmed.

According to some hypotheses, the problem could be linked to a buffer overflow or a race condition."

Extract from the LinkedIn post of Naïm Aouaichia, cybersecurity engineer

A long-standing problem

This vulnerability has a long history, having been present in GNU/Linux systems for many years. over a decade. It affects all Linux distributions, including Debian, Ubuntu, RedHat and others.

Despite the importance of this flaw, there are currently no no correction available. Developers are still debating which aspects of the flaw really affect security, which is delaying the release of a patch.

Disclosure process

Researcher Margaritelli, who made the discovery, worked tirelessly for three weeks to alert the open source community and help coordinate patching efforts. However, it met with a great deal of resistance from developersSome are reluctant to accept the existence of this flaw in their code. This underlines the challenges facing vulnerability management in the open source world.

Some accuse him of trying to boost his popularity. But let's face it: the researcher has indeed discovered a major flaw that everyone has been ignoring for over 10 years.

Canonical (Ubuntu) and RedHat have confirmed the seriousness of the situation and are actively working on a solution. Full disclosure of the technical details of the flaw is planned. October 6This increases the pressure for a rapid patch release.

The roadmap is as follows:

• September 30: Initial disclosure to the Openwall security mailing list
• October 6: Public revelation with all the elements of vulnerability

Why is it complicated to correct the flaw?

Margaritelli indicated from the outset that it would probably be necessary to at least three to six CVE identifiers (Common Vulnerabilities and Exposures) to cover all aspects of the problem. This means that there are several potential attack vectors, each requiring specific analysis and resolution.

What are the risks for you?

As we now know, you must absolutely avoid exposing your IPP services to the Internet (port 631 should be blocked on firewalls).

Although this flaw is critical, it is not so easily exploited. It requires a high level of technical expertise, which means that, for the time being, only highly skilled attackers could make use of it. The details of the flaw are not yet public, limiting its impact. But this should not make you complacent. You need to remain vigilant, because once full disclosure has been made, exploitation attempts will multiply.

What to do in the meantime?

Pending an official patch, here are some best practices to limit the risks:

1. Watch for official announcements Stay informed about security updates released by your Linux distribution. These announcements will let you know when a patch is available.
2. Reinforce your firewall configuration Make sure your servers are not unnecessarily exposed to the Internet. Restrict access to essential ports and, above all, do not expose port 631!
3. Limit service exposure Reduce the number of services listening publicly to a minimum by switching off unnecessary services or having them listen on 127.0.0.1.
4. Get ready for rapid deployment As soon as a patch is released, be ready to install it immediately to protect your machines.
5. Re-evaluate your backups : Make sure you have a good outsourced backup (LRob already has one, but it's not enough!). we encourage everyone to have their own back-up).

Conclusion: remain vigilant but serene

This RCE flaw is undoubtedly one of the most serious to be discovered in the GNU/Linux ecosystem in a long time. However, it's important not to panic. No system is free of flaws, and Linux remains the most reliable and secure operating system. It's worth remembering that most servers don't have a CUPS service running, but if they do, then take extra care. By adopting the recommended security measures and keeping an eye on official announcements, you can minimize the risks. The open source world is generally quick to react and will certainly be able to overcome this ordeal effectively, despite the internal divergences inherent in collaborative work.

Keep an eye on upcoming patches and make sure your systems are ready for them. IT security is an ongoing challenge, but staying proactive will ensure that your WordPress servers and clients stay protected.

LRob is keeping a very close eye on this, and if the servers aren't affected, I guarantee that we'll fix this global flaw as soon as the patch is available.

Finally, for those who will argue that "Linux isn't secure", here's a little comparison Linux VS Microsoft.

The truth is: there's no such thing as 100% safety, and anyone who claims otherwise is either lying or ignorant! So leave dogmatism aside. No one is spared from vulnerabilities, so it's a question of doing our best and remaining vigilant to make intrusions as difficult as possible.

Sources :

• LinkedIn post by Naïm Aouaichia, cybersecurity engineer
• Thread by Simone Margaritelli on X
• Article on Korben
• Article on securityonline.info