- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
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
You must log in or # to comment.
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.
Edit: Okay, after reading the blog post, and this fantastic bug report, it sounds like to print to a CUPS server, you send it a message on port 631 using an IPP (some print protocol) server. CUPS then requests attributes of the IPP server, one of which being the print filter command to run (“Foomatic-rip”) to use to convert a PS or PDF into native print code. By requesting attributes, an exploit involving string escaping through the use of unexpected spaces or quotes can override the Foomatic print command. Arbitrary text can be supplanted, which will then be executed by the CUPS server.
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
Edit: I’m mistaken
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.
Maybe my information is out of date then
No maybe about it.
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.
Man, this is such a silly and unfortunate exploit. Damn! I hope it gets patched quick.
