6 ms·

Cups Remote Code Execution Vulnerability Fix Available

45 points by heisenbit 2y ago

jmclnx 2y ago
This morning I just installed the fixed Slackware Packages for cups. It became available on Oct 1 18:00 UTC: >(* Security fix *) >patches/packages/cups-filters-1.28.17-x86_64-2_slack15.0.txz: Rebuilt. Mitigate security issue that could lead to a denial of service or the execution of arbitrary code. Rebuilt with --with-browseremoteprotocols=none to disable incoming connections, since this daemon has been shown to be insecure. If you actually use cups-browsed, be sure to install the new /etc/cups/cups-browsed.conf.new containing this line: >BrowseRemoteProtocols none >For more information, see: >https://www.cve.org/CVERecord?id=CVE-2024-47176 https://www.cve.org/CVERecord?id=CVE-2024-47176
- USiBqidmOOkAqRb 2y ago
  JSless alternative https://nvd.nist.gov/vuln/detail/CVE-2024-47176 https://nvd.nist.gov/vuln/detail/CVE-2024-47176
candiddevmike 2y ago
CUPS and all of the other "root but with chroot" daemons like Postfix use a legacy security model that will hopefully be modernized to use things like namespaces and cgroups. Hopefully this is a wake up call to start pursuing these migrations faster. Right now it's really painful to get Postfix and friends to not run as root, and the maintainers are very hostile towards enabling this behavior.
- noinsight 2y ago
  You can already sandbox services very effectively when you run them under systemd. It’s really nice to be able to harden things solely through systemd.
- orf 2y ago
  > and the maintainers are very hostile towards enabling this behavior. Got any links to read more?
axoltl 2y ago
Canonicals little jab under the "importance of coordinated disclosure" section rubs me the wrong way. They seem to be under the impression the recipient of a vulnerability report gets to set the rules, much like when a project receives a bug report. They don't. That power rests solely with the researcher, and they can do as they see fit.
- appendix-rock 2y ago
  You’re conflating power and proper practice. “Yeah, well, they’re allowed to” is a comment that’s never, ever worth making, because EVERYONE already knows it. The need to always kick up a fuss about “doing whatever I want in my land” always feels like a weirdly American reflex that’s always a little ignorant of the context of the actual discussion taking place.
  - axoltl 2y ago
    You're making it sound like there is a well-agreed-upon way of disclosing vulnerabilities ("_proper_ practice"). I'm a security researcher and this particular discussion has been going on for well over a decade at this point. My point wasn't "they're allowed to do whatever they want". My point was there are many different viewpoints on the matter and Canonical seems to be insisting theirs is the correct one. (Also, I'm not American)
    - close04 2y ago
      Canonical's statement hits all the right notes. It's a short summary of what coordinated disclosure is and a gentle reminder of why it's important to follow that practice, without really pointing any fingers. I don't see something in Canonical's actions that suggests they actively harmed the process, or that the way the early disclosure was handled was in the users' interest. You say it "rubs you the wrong way" without pointing out what exactly you think is wrong with it. One could easily understand that as a security researcher you just want to do whatever you want, when you want it, without anyone pointing fingers at you. Your attitude that "That power rests solely with the researcher, and they can do as they see fit" while technically correct exudes bad faith. Further explanation that "there's no consensus" isn't making it any better.
mjw1007 2y ago
I remember Ubuntu's decision to abandon its original "no open ports in the default install" policy for the sake of zeroconf/mdns was controversial at the time. https://wiki.ubuntu.com/ZeroConfPolicySpec https://wiki.ubuntu.com/ZeroConfPolicySpec https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019137.html https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019...
cypherpunks01 2y ago
Attacking UNIX Systems via CUPS, Part I, 2024-09-26 (linked at end of page) https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems...
deleted 2y ago
[deleted]
4oo4 2y ago
This is missing portant info. Nowhere does it say what the fixed package versions are, this is crucial for auditing whether you are fully patched.

45 points by heisenbit 2y ago

This morning I just installed the fixed Slackware Packages for cups. It became available on Oct 1 18:00 UTC: >(* Security fix *) >patches/packages/cups-filters-1.28.17-x86_64-2_slack15.0.txz: Rebuilt. Mitigate security issue that could lead to a denial of service or the execution of arbitrary code. Rebuilt with --with-browseremoteprotocols=none to disable incoming connections, since this daemon has been shown to be insecure. If you actually use cups-browsed, be sure to install the new /etc/cups/cups-browsed.conf.new containing this line: >BrowseRemoteProtocols none >For more information, see: >https://www.cve.org/CVERecord?id=CVE-2024-47176 https://www.cve.org/CVERecord?id=CVE-2024-47176

USiBqidmOOkAqRb 2y ago
JSless alternative https://nvd.nist.gov/vuln/detail/CVE-2024-47176 https://nvd.nist.gov/vuln/detail/CVE-2024-47176

candiddevmike 2y ago

CUPS and all of the other "root but with chroot" daemons like Postfix use a legacy security model that will hopefully be modernized to use things like namespaces and cgroups. Hopefully this is a wake up call to start pursuing these migrations faster. Right now it's really painful to get Postfix and friends to not run as root, and the maintainers are very hostile towards enabling this behavior.

noinsight 2y ago
You can already sandbox services very effectively when you run them under systemd. It’s really nice to be able to harden things solely through systemd.
orf 2y ago
> and the maintainers are very hostile towards enabling this behavior. Got any links to read more?

axoltl 2y ago

Canonicals little jab under the "importance of coordinated disclosure" section rubs me the wrong way. They seem to be under the impression the recipient of a vulnerability report gets to set the rules, much like when a project receives a bug report. They don't. That power rests solely with the researcher, and they can do as they see fit.

appendix-rock 2y ago
You’re conflating power and proper practice. “Yeah, well, they’re allowed to” is a comment that’s never, ever worth making, because EVERYONE already knows it. The need to always kick up a fuss about “doing whatever I want in my land” always feels like a weirdly American reflex that’s always a little ignorant of the context of the actual discussion taking place.
- axoltl 2y ago
  You're making it sound like there is a well-agreed-upon way of disclosing vulnerabilities ("_proper_ practice"). I'm a security researcher and this particular discussion has been going on for well over a decade at this point. My point wasn't "they're allowed to do whatever they want". My point was there are many different viewpoints on the matter and Canonical seems to be insisting theirs is the correct one. (Also, I'm not American)
  - close04 2y ago
    Canonical's statement hits all the right notes. It's a short summary of what coordinated disclosure is and a gentle reminder of why it's important to follow that practice, without really pointing any fingers. I don't see something in Canonical's actions that suggests they actively harmed the process, or that the way the early disclosure was handled was in the users' interest. You say it "rubs you the wrong way" without pointing out what exactly you think is wrong with it. One could easily understand that as a security researcher you just want to do whatever you want, when you want it, without anyone pointing fingers at you. Your attitude that "That power rests solely with the researcher, and they can do as they see fit" while technically correct exudes bad faith. Further explanation that "there's no consensus" isn't making it any better.

mjw1007 2y ago

I remember Ubuntu's decision to abandon its original "no open ports in the default install" policy for the sake of zeroconf/mdns was controversial at the time. https://wiki.ubuntu.com/ZeroConfPolicySpec https://wiki.ubuntu.com/ZeroConfPolicySpec https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019137.html https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019...

cypherpunks01 2y ago

Attacking UNIX Systems via CUPS, Part I, 2024-09-26 (linked at end of page) https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems...

deleted 2y ago

[deleted]

4oo4 2y ago

This is missing portant info. Nowhere does it say what the fixed package versions are, this is crucial for auditing whether you are fully patched.