Worried about that critical RCE Linux bug? Here's why you can relax

People in Linux circles were getting worried this week. 

On Monday, Italian programmer Simone Margaritelli, who goes by the handle @evilsocket, claimed that there was an unauthenticated Remote Code Execution (RCE) with a Common Vulnerability Scoring System (CVSS) score of 9.9 that could be used against all Linux systems. 

Also: 5 Linux terminal apps that are better than your default – and free to install

For those who aren’t security experts, a score of 9.9 is as bad as it gets. But what Margaritelli didn’t mention is that, by default, almost no properly secured system could actually be attacked via the vulnerabilities. 

Mind you, I did say “properly secured.” It appears many — hundreds of thousands, in fact — aren’t correctly locked down. As Margaritelli wrote in a blog post, “I’ve been scanning the entire public internet IPv4 ranges several times a day for weeks, sending the UDP packet and logging whatever connected back. And I’ve got back connections from hundreds of thousands of devices.”

Also: Rust in Linux now: Progress, pitfalls, and why devs and maintainers need each other

Let me start by explaining that the problem is not with Linux per se. It’s with the OpenPrinting CUPS print program. CUPS is an open-source system that uses the Internet Printing Protocol (IPP) to manage printers, print requests, and print queues. When it is installed and running, it enables computers to act as print servers. 

As Margaritelli explained, the problem is that, if properly exploited, “A remote unauthenticated attacker can silently replace existing printers’ (or install new ones) IPP urls with a malicious one, resulting in arbitrary command execution (on the computer) when a print job is started (from that computer).”

Also: Linux and open-source documentation is a mess: Here’s the solution

In its CUPS security bulletin, Red Hat explained that to exploit it, the following conditions must be met:

1. The cups-browsed service has manually been enabled or started.

2. An attacker has access to a vulnerable server, which:

1. Allows unrestricted access, such as the public Internet or

2. Gains access to an internal network where local connections are trusted

3. The attacker advertises a malicious IPP server, thereby provisioning a malicious printer

4. A potential victim attempts to print from the malicious device

5. The attacker executes arbitrary code on the victim’s machine

Where to begin? First, who in their right mind puts any computer on the onternet with unrestricted access? 

I’m also curious why such a computer would have trusted local connections. Forget about CUPS; this is just asking for your server and everything on your network to be hacked. 

Also: How to run a Windows app on Linux with Wine

This is no 9.9 problem. Red Hat and all the other Linux distros addressing this linked set of security holes rank it as important. The individual CVE CVSS scores of the four bugs range from 6.1 to 8.2. 

As Ilkka Turunen, the open-source supply chain company Sonatype‘s Field CTO, wrote on LinkedIn, “Good news then — it’s an RCE but with several mitigations, including the fact the attacker needs to be able to connect to a computer via UDP, which is widely disabled on network ingress, and the service is usually not on by default. It seems like the real-world impact is low.”

That sounds fair to me. 

This is a classic example of a service that doesn’t validate or sanitize its inputs. The classic cartoon example of this kind of exploit is Little Bobby Tables. Efforts are afoot to stop this kind of exploit in CUPS, but the final patches haven’t been written yet.

As Margaritelli rightfully pointed out, the CUPS code itself is a mess. It really needs to be cleaned up and fixed. Margaritelli reported that many of the programmers involved with CUPS resisted efforts to point out the bugs (never mind fixing them). 

That’s not cool, guys. Not cool at all. 

How to see if you’re running CUPS

For the moment, the fix is to see if you’re running CUPS with such a command as:

$ sudo systemctl status cups-browsed

If it’s not running, you’re done. No problem. 

If you are, and you don’t need your machine to be a print server, run:

$ sudo  systemctl stop cups-browsed

Which will stop the problem in its tracks. To stop it from starting again, run:

$ sudo systemctl disable cups-browsed

While you’re at it, for pity’s sake, if you have a server running naked on the Internet, stop it! Put a firewall on that thing and, in particular, block any outside traffic to port 631, the default IPP port. 

Let’s say you have a busy print server behind a firewall. Are you out of the woods? No, you’re not. Someone on your local network who needs to access port 631 to print documents could attack the server.

Also: Google’s hidden AI tool turns your text into stunningly lifelike podcasts – for free

In that case, you must edit the /etc/cups/cups-browsed.conf file. Specifically, you must set the BrowseRemoteProtocols directive values from the default “dnssd cups” to “none”. Then restart the cups-browsed service with the command: 

$ sudo systemctl restart cups-browsed

Make no mistake about it, though once the patches are available, you’ll still need to patch as soon as possible. But, really, so long as you didn’t pull the boneheaded stunt of putting your Linux computers on the internet without a firewall, you should be fine.