I hope this goes without saying but please do not run this on machines you don’t own.
The good news:
- the exploit seems to require user action
The bad news:
-
Device Firewalls are ineffective against this
-
if someone created a malicious printer on a local network like a library they could create serious issues
-
it is hard to patch without breaking printing
-
it is very easy to create printers that look legit
-
even if you don’t hit print the cups user agent can reveal lots of information. This may be blocked at the Firewall
TLDR: you should be careful hitting print
Man, this is such a silly and unfortunate exploit. Damn! I hope it gets patched quick.
CUPS facing the public internet sounds a bit crazy. Why would you print when not physicly near the printer?
I think this would likely be most troublesome on some of the OG internet users that got a whole freaking /8, /10, or /12 or something like AT&T or universities. Up until very recently, and possibly even to the present, these organizations had such large IPv4 space, that there was no need to do NAT, and each device had a publicly addressable IP.
https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks
Everything would still be behind a firewall though
everything should be behind a firewall
The questionable commit:
{ // Add the first line of localized text... cupsFilePrintf(fp, "*%s.%s %s/", lang->language, ppd_option, ppd_choice); while (*text && *text != '\n') { // Escape ":" and "<"... if (*text == ':' || *text == '<') cupsFilePrintf(fp, "<%02X>", *text); else cupsFilePutChar(fp, *text); text ++; } cupsFilePuts(fp, ": \"\"\n"); }Can someone explain to me how this allows arbitrary code execution? As far as I can see, all it does iterate through a string and markup some special characters.
From what I understand, this allows arbitrary command execution. So, an attacker can specify a string of text that something on the affected system will just plop into a command line and execute.
Take a look at the exploit code
deleted by creator
Any self-respecting distro pushed an update to fix this days ago, so just updating (and restarting cups) will do. But if you don’t print anyway, you might as well disable it.
There is currently no fix available
Not true, Arch and Ubuntu (the ones I personally checked on) already pushed patches that disabled cups browsed by default, removing the service listening on 631.
What? I got a patch on Arch yesterday.
I mean both Red Hat and Ubuntu did ship updates to change the config of cups-browsed, so I don’t think that’s correct.
