The Announcement Late last month there was an announcement of a “severity 9.9 vulnerability” allowing remote code execution that affects “all GNU/Linux systems (plus others)”…
This seems very one-sided. Sure, the disclosure was not handled perfectly. However, this post completely ignores the terrible response by the CUPS team.
The point on NAT is certainly fair and prevented this from being a much bigger issue. Still, many affected systems were reachable from the internet.
Lastly, the author tries to downplay the impact of an arbitrary execution vulnerabilty because app armour might prevent it from fully compromising the system. Sure, so I guess we don’t need to fix any of those vulnerabilities /s.
I think it perfectly highlights what can happen when the risk/severity is blown out of proportion. People will latch on to that and waste precious time and energy defending that.
If the original guy had just published “CUPS has a RCE, firewall it if you haven’t already”, the issue would have been patched in the next release, and the world would have kept turning.
It was a really cool bug, and a great find, it didn’t need the hype
Wasn’t the CVE fixed in a reasonable time frame?
I seriously doubt that the maintainers would have ignored it if it wouldn’t have been discussed so publicly.
AFAIK, to exploit it, you need network access to CUPS then add the printer and then the client needs to add/select a new printer on the client device and actively print something.
If CUPS is reachable from the internet, then the system/network is misconfigured anyway, no excuse for ignoring the issue but those systems have other sever issues anyway.
As far as I’m aware, the exploit requires someone to try printing using a malicious networked printer. It is a vulnerability, yes, but it affects essentially nobody. Who tries manually printing something on a server exposed to the internet?
Although for local network access, like in a corporation using Linux on desktops, the vulnerability is an actual risk.
Ive worked with thermal printers used in POS, and usually they use a different protocol than notmal printing so you’re not using cups (basically you send “commands” with text and its position). But i am sure there are some exceptions…
This seems very one-sided. Sure, the disclosure was not handled perfectly. However, this post completely ignores the terrible response by the CUPS team.
The point on NAT is certainly fair and prevented this from being a much bigger issue. Still, many affected systems were reachable from the internet.
Lastly, the author tries to downplay the impact of an arbitrary execution vulnerabilty because app armour might prevent it from fully compromising the system. Sure, so I guess we don’t need to fix any of those vulnerabilities /s.
I think it perfectly highlights what can happen when the risk/severity is blown out of proportion. People will latch on to that and waste precious time and energy defending that.
If the original guy had just published “CUPS has a RCE, firewall it if you haven’t already”, the issue would have been patched in the next release, and the world would have kept turning.
It was a really cool bug, and a great find, it didn’t need the hype
Wasn’t the CVE fixed in a reasonable time frame? I seriously doubt that the maintainers would have ignored it if it wouldn’t have been discussed so publicly.
AFAIK, to exploit it, you need network access to CUPS then add the printer and then the client needs to add/select a new printer on the client device and actively print something.
If CUPS is reachable from the internet, then the system/network is misconfigured anyway, no excuse for ignoring the issue but those systems have other sever issues anyway.
As far as I’m aware, the exploit requires someone to try printing using a malicious networked printer. It is a vulnerability, yes, but it affects essentially nobody. Who tries manually printing something on a server exposed to the internet?
Although for local network access, like in a corporation using Linux on desktops, the vulnerability is an actual risk.
I was thinking embedded clients would be the bigger issue. Stuff like POS machines, that sort of thing.
Even there, if the stars align (network access, cups being used), you still need to convince the user of the device to switch printer.
Ive worked with thermal printers used in POS, and usually they use a different protocol than notmal printing so you’re not using cups (basically you send “commands” with text and its position). But i am sure there are some exceptions…