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 what action to take.

UPDATE 29/09/2024: These flaws only affect 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 Margaritelli, discovered this set of faults at the beginning of September.

This concerns CUPS, the Linux printing service. The researcher highlights the possibility of 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 assessed at 9.9).

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

«Some rumours suggest that this flaw is linked to vulnerabilities in CUPS, the printing service. Yes, your printers may be at the centre of this. To be confirmed.

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

Extract from the LinkedIn post by 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. more than 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 introduction 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 developers, Some are reluctant to accept the existence of this flaw in their code. This highlights 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 6 October, This increases the pressure for a patch to be released quickly.

The roadmap is as follows:

• 30 September: Initial disclosure to the Openwall security mailing list«
• 6 October: Public disclosure of the full extent of the 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, it is absolutely essential to avoid exposing your IPP services to the Internet (port 631 should be blocked in 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 that shouldn't make you complacent. You need to remain vigilant, because once full disclosure has been made, attempts to exploit it will multiply.

What to do in the meantime?

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

1. Keep an eye out for official announcements Stay informed about security updates released by your Linux distribution. These announcements will tell you when a patch is available.
2. Reinforce the configuration of your firewalls 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 exposure of services 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 published, be ready to install it immediately to protect your machines.
5. Re-evaluate your back-ups : Make sure you have a good outsourced backup (LRob already does this but we encourage everyone to have their own back-up).

Conclusion: remain vigilant but calm

This RCE flaw is undoubtedly one of the most serious to be discovered in the GNU/Linux ecosystem for a long time. However, it is 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 out for official announcements, you can minimise the risks. The open source world generally reacts quickly and will certainly be able to overcome this ordeal effectively, despite the internal differences inherent in collaborative working.

Keep an eye on upcoming patches and make sure your systems are ready for them. IT security is a constant challenge, but being 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 can 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 quick comparison Linux VS Microsoft.

The truth is: safety at 100% never exists, and anyone who claims otherwise is either lying or ignorant! So leave dogmatism aside. No one is immune to security breaches, 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