• stuner@lemmy.world
    link
    fedilink
    arrow-up
    25
    arrow-down
    5
    ·
    2 months ago

    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.

    • CameronDev@programming.dev
      link
      fedilink
      arrow-up
      25
      ·
      2 months ago

      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

    • ShortN0te@lemmy.ml
      link
      fedilink
      arrow-up
      15
      ·
      2 months ago

      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.

    • deadcadeA
      link
      fedilink
      arrow-up
      9
      arrow-down
      2
      ·
      2 months ago

      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.

        • deadcadeA
          link
          fedilink
          arrow-up
          4
          ·
          2 months ago

          Even there, if the stars align (network access, cups being used), you still need to convince the user of the device to switch printer.

        • CodeGameEat@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 months ago

          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…

      • koper@feddit.nl
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        Even if you computer is not exposed to the internet: are you certain that every other device on the network is safe (even on public wifi)? Would you immediately raise the alarm if you saw a second printer in the list with the same name, or something like “Print to file”? I think I personally could fall for that under the right circumstances.

        • deadcadeA
          link
          fedilink
          arrow-up
          1
          ·
          2 months ago

          That was a possibility with this exploit, but realistically that doesn’t affect nearly as many people as “All GNU/Linux systems”.