5 ms·

I don't know if I would say it's a nothing burger, but i don't see how it affects important servers. It might impact a number of linux desktops and, if they are

by bshipp 2y ago

I don't know if I would say it's a nothing burger, but i don't see how it affects important servers. It might impact a number of linux desktops and, if they are linked to important servers, provide a backdoor access into important services. Being able to run arbitrary code in a root account with no authentication would seem to be a pretty important security breach, although I don't think it's quite the level of danger it was built up to be.

andersa 2y ago
But why would such desktops be exposed to the public internet directly?
- bshipp 2y ago
  Likely no good reason. But he seemed to have identified many many systems that were, inexplicably, exposing port 631 to the internet. There is some reason people are doing it and, given the number of target systems, it must be some sort of default configuration. > "This thing is packaged for anything, in some cases it’s enabled by default, in others it’s not, go figure . Full disclosure, I’ve been scanning the entire public internet IPv4 ranges several times a day for weeks, sending the UDP packet and logging whatever connected back. And I’ve got back connections from hundreds of thousands of devices, with peaks of 200-300K concurrent devices. This file contains a list of the unique Linux systems affected. Note that everything that is not Linux has been filtered out. That is why I was getting increasingly alarmed during the last few weeks."
- bonzini 2y ago
  The 9.9 issue is the foomatic-rip vulnerability; not cups-browsed listening on 0.0.0.0. See here: > LAN: a local attacker can spoof zeroconf / mDNS / DNS-SD advertisements (we will talk more about this in the next writeup) and achieve the same code path leading to RCE.
  - andersa 2y ago
    I see. This sounds like a problem for people using public wifi...
    - bonzini 2y ago
      Maybe, maybe not. If I understand correctly, you still need to print something to the printer to achieve RCE via foomatic-rip.
      - tsimionescu 2y ago
        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 2y ago
        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 2y ago
        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 2y ago
    I believe you'd still need cups-browsed installed, enabled & configured to accept remote printer broadcasts, _and_ have foomatic installed locally in order to get hit by this. Modern version of cups will basically only talk to "driverless" IPP Everywhere printers, which all understand a common set of raster formats and hence have no need for printer-model specific software like foomatic-rip to be installed. They do this via mDNS, which means you don't need cups-browsed to be installed either.
- dumpsterdiver 2y ago
  The likely target that emerged in my mind reading this is mom and pop point of sale systems. The operators of such systems are completely oblivious to such risks, and the underpaid PoS software support team following a script to restart CUPS probably are as well.

by bshipp 2y ago

andersa 2y ago

But why would such desktops be exposed to the public internet directly?

bshipp 2y ago
Likely no good reason. But he seemed to have identified many many systems that were, inexplicably, exposing port 631 to the internet. There is some reason people are doing it and, given the number of target systems, it must be some sort of default configuration. > "This thing is packaged for anything, in some cases it’s enabled by default, in others it’s not, go figure . Full disclosure, I’ve been scanning the entire public internet IPv4 ranges several times a day for weeks, sending the UDP packet and logging whatever connected back. And I’ve got back connections from hundreds of thousands of devices, with peaks of 200-300K concurrent devices. This file contains a list of the unique Linux systems affected. Note that everything that is not Linux has been filtered out. That is why I was getting increasingly alarmed during the last few weeks."
bonzini 2y ago
The 9.9 issue is the foomatic-rip vulnerability; not cups-browsed listening on 0.0.0.0. See here: > LAN: a local attacker can spoof zeroconf / mDNS / DNS-SD advertisements (we will talk more about this in the next writeup) and achieve the same code path leading to RCE.
- andersa 2y ago
  I see. This sounds like a problem for people using public wifi...
  - bonzini 2y ago
    Maybe, maybe not. If I understand correctly, you still need to print something to the printer to achieve RCE via foomatic-rip.
    - tsimionescu 2y ago
      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 2y ago
        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 2y ago
        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 2y ago
  I believe you'd still need cups-browsed installed, enabled & configured to accept remote printer broadcasts, _and_ have foomatic installed locally in order to get hit by this. Modern version of cups will basically only talk to "driverless" IPP Everywhere printers, which all understand a common set of raster formats and hence have no need for printer-model specific software like foomatic-rip to be installed. They do this via mDNS, which means you don't need cups-browsed to be installed either.
dumpsterdiver 2y ago
The likely target that emerged in my mind reading this is mom and pop point of sale systems. The operators of such systems are completely oblivious to such risks, and the underpaid PoS software support team following a script to restart CUPS probably are as well.