Major Linux distributions AND Google Chrome use a printing stack called Common Unix Printing System or CUPS. There has been a vulnerability in the library (actually, 4 vulnerabilities in tandem) for years that was just patched.
The vulnerability was discovered, investigated, publicised, and dramatised (with very good reason) by Simone Margaritelli, who has described his process here.
The vulnerability was severe for the following reasons:
- Vulnerable to remote attackers, as opposed to requiring physical device access
- Does not involve tricking or fooling a user, as is the case with many phishing or "social engineering" attacks
- Available on nearly all linux devices rather than being specific to certain hardware configurations
- Allowed the attacker to run any command they like, also known as arbitrary code execution
The severity was mitigated by the following factors:
- The attacker needs network access to a specific port on the computer, which is often blocked by ISPs and firewalls, highlighting the importance of carefully configured firewalls
- The commands chosen to be executed by the attacker are run as the same user that runs CUPS commands, which does not have admin privileges, highlighting the importance of strict permission management
The four component vulnerabilities are:
- CVE-2024-47176, which allows all data packets from all sources on UDP port 631 to ask for an arbitrary (and malicious, if the data packet so specifies) printer's attributes
- CVE-2024-47076, which does not sanitize attributes received from a printer before passing it on to the rest of the CUPS system
- CVE-2024-47175, which does not sanitize attributes received from a printer before writing them to a temporary printer-description file
- CVE-2024-47177, which allows arbitrary command execution from a printer-description file
The chain of events in the attack is as follows:
- The CUPS service that listens for printers is started, either automatically or manually
- The attacker has access to the target computer, either because the target machine is exposed to the public internet without firewalls or the attacker has managed to get access to a private network that the target trusts
- The attacker falsely and maliciously advertises a fake printer to the target computer, creating the printer-description file (containing an arbitrary command) and setting it as the default printer.
- The victim attempts to print a file, at which point the command embedded into the printer-description file is triggered. Remember that "Print to PDF" also goes through the printer utility.
Thankfully, if your computer does not connect to the internet directly but rather through a router, your computer was likely never vulnerable.
This was rated a 9.9 on the security scale by multiple security researchers, which may be overselling the vulnerability a bit. Always better to err on the side of caution, however.
I said earlier that this vulnerability was dramatised. It took Simone only two days to figure out the vulnerability in its entirety. However, twenty-two days after making the initial security report and being active in conversations about it, he was unable to convince the maintainers that this vulnerability was worth fixing.
The standard responsible disclosure process is that you reach out to the developers in private, rather than publishing the vulnerability publicly. Obviously, this is to prevent attackers from learning about and taking advantage of the vulnerability before a fix is out.
However, this process seems to be broken in the OpenPrinting organisation. Simone was expected to jump through hoops to prove that this vulnerability is worth fixing. It seems to be a case of "murder your darlings", where people are so attached to their creations that they strongly dismiss criticism.
When 22 days of making his case to the developers didn't show results, Simone took to twitter. With two tweets, he managed to get the team working on the fix, which was then soon published to all software repositories.
To be clear, I don't think this means open source software is less secure - this inability to criticise your own work is something I see in my company as well, writing proprietary code.