[tsimionescu]

You do, until someone finds a way to exploit the other buffer overflows. But also, this attack is persistent: you get infected without any interaction at the coffee shop, and two years later when you print something at home on your well secured network: BAM!

[aragilar]

Uh, how? Unless somehow it stays around even though you've left the network (which I didn't think happens, but I could be wrong), this lasts just as long as the mDNS attacking server is on the network?

This to me feels like the author missed why the system was set up the way it was, and therefore doesn't present useful solutions.

[tsimionescu]

Per the article, the attack works like this:

The attacker sends a malicious UDP datagram to the target computer, telling it is a printer available at ATTACKER_CONTROLLED_URI.

The vulnerable computer receives this packet and proceeds to download the "printer information" (attacker-controlled printer scripts) from ATTACKER_CONTROLLED_URI and store it in a PPD file as an available printer, potentially overwriting an existing printer.

There is no user intervention needed, nor any notifications to the user, up to this point. The PPD files are persistent: they will stick around ~forever on your system until some other printer replaces them, or you manually delete them.

Whenever you want to print, CUPS looks for all the PPD files currently on the system and provides print options based on them. If you choose to print using the malicious printer (which might look like one of your known printers), the information in the attacker-controlled PPD file will be used by CUPS, including Foomatic scripts that can run more or less arbitrary code with root privileges.

The biggest issue with all of this is that Linux doesn't distinguish between trusted LANs, where arbitrary printers connecting to you is actually a pretty nice feature; and public untrusted LANs, where this is DEFINITELY not a good idea. Also, the fact that your printer infra can run arbitrary code as root, code supplied by the remote printer itself, is another level of crazy.

[yrro]

> Linux doesn't distinguish between trusted LANs [...] and public untrusted LANs

Gotta be the annoying and point out here that Linux is a kernel. Fedora Workstation, for instance, has firewalld installed & enabled by default, which does apply different policies to different network zones. Hook a default system up to a hostile coffee shop, and TCP/UDP ports <= 1024 are blocked by the default FedoraWorkstation zone. NetworkManager connections have a 'zone' property that the user can change to 'home', 'trusted', etc.

> Also, the fact that your printer infra can run arbitrary code as root, code supplied by the remote printer itself, is another level of crazy

Only, it seems, if non-default legacy printer drivers (foomatic) and discovery services (cups-browsed) are present. And doesn't cups run backends as an unprivileged 'lp' user? And confined by MAC (again, in the Red Hat world, SELinux confines it to the cupsd_t domain). So not _that_ crazy.

[bonzini]

Disabling foomatic seems hard since the PPD can be distributed by the attacker and foomatic-rip is part of the cups-filter package. But yes, lp user + SELinux should be enough to make this not a 9.9.

[yrro]

I actaully didn't realise that foomatic is part of cups-filters now?! On the other hand - it's only 'activated' by cups-browsed, if I understand correctly, at least by the currently disclosed set of vulnerabilities... let's hope an attacker can't craft a printer that will trick cups itself into configuring a dodgy print destination...

[aragilar]

Oh, I get the flow. Only what I'd seen previously is the cups-browsed PPDs only last as long as the source is around (which again, is what I'd seen previously, but I haven't verified the code to see when the cleanup happens, so I'm 100% ready to be wrong). Hence the objection to the "2 years later" comment.

The original article seems to spend more time being vague about the actual issue (it's notable that the PoC video makes it really hard to see the steps), and if this vagueness was in the original security reports, I'm not surprised it wasn't well received (c.f. the vague bug reports curl gets).