A severe vulnerability in OpenSSH, dubbed "regreSSHion" (CVE-2024-6387), has been discovered by the Qualys Threat Research Unit, potentially exposing

cross-posted from: https://lemmy.pt/post/5733711

A severe vulnerability in OpenSSH, dubbed “regreSSHion” (CVE-2024-6387), has been discovered by the Qualys Threat Research Unit, potentially exposing

    • Telorand@reddthat.com
      14·
      4 months ago

      They could get RasPis below 4th gen running outdated software, I guess. I think I read elsewhere that Debian already had a patch out some time ago, so that number is also likely diminishingly small.

      • d_k_bo@feddit.org
        7·
        4 months ago

        I have no idea when I last updated my RasPi 0s (none of which is exposed to the public).

        • oKtosiTe@lemmy.world
          4·
          4 months ago

          Most images and distros are just Raspbian at their core and as such are pretty easy to upgrade.

          I upgraded my homebridge/pihole from Bullseye to Bookworm just a few days ago and it went off without a hitch.

          • IceFoxX@lemm.ee
            3·
            4 months ago

            Did the same with raspi3… It broke too many things for me and couldn’t be restarted. I then completely reinstalled it.

            • oKtosiTe@lemmy.world
              2·
              4 months ago

              Aww that sucks. To be fair I did take a full image backup before attempting the upgrade in case something went awry.

              • IceFoxX@lemm.ee
                2·
                4 months ago

                I also had a complete backup, but I was also considering reinstalling it at the time anyway. Accordingly, only partially restored data. But you should definitely make a backup, that’s true.

          • Pacmanlives@lemmy.world
            1·
            4 months ago

            Has had Musl for awhile here is the install stage https://www.gentoo.org/downloads/#amd64-advanced . Bunch of docs on their wiki too. Gentoo is a rolling release you are correct but there is testing and stable branches. Stable branch is enterprise production ready. I know of a few hardware vendors that are using a custom gentoo builds under the hood. One of them is a big name storage array company that people spend hundreds if not millions on their arrays.

            My experience with Void was hyper rolling release . You get things quickly kind of like Arch.

            Gentoo stable runs a little bit older software for stability sake. With that being said you can mix and match stable with testing. I would assume there is some gotchas but I have not run into any yet. I am running the testing branch just for KDE software right now to have the latest and greatest KDE but a super stable base.

            Definitely something to take a look at if you’re a more advanced user. I am coming back to Gentoo after about 15 years off and just loving it. Compile times are not that bad with new hardware. My Intel NUC I am running on is crushing it. I remember X taking like a week to compile back in like 2003 lol

            • GolfNovemberUniform@lemmy.ml
              1·
              4 months ago

              Sorry but imo “compilation” and “production” cannot be used in one sentence. Imagine the electricity bills and compilation times on office machines with i3s or Celerons

              • Pacmanlives@lemmy.world
                1·
                4 months ago

                Everything gets compiled at some point to be able to run.

                Lot of people running large gentoo server farms will compile and run binary’s. Even Gentoo is officially supporting binary packages for their stable branch. Package set is ever growing right now too

                • GolfNovemberUniform@lemmy.ml
                  1·
                  4 months ago

                  What I meant is that compiling the same program on 100 machines is a horrifying waste of resources and downtime. Binaries exist but it destroys the point of Gentoo that was never meant for production in the first place.

  • dino@discuss.tchncs.deEnglish
    16·
    4 months ago

    Question if I update my server and it has the new SSH (patched) package. Is that enough or do I have to restart the server as well? How can I check if the old SSH is in use currently?

    • Kusimulkku@lemm.ee
      6·
      4 months ago

      Some package managers have a command to see if anything is in need of restart. Zypper has ps -s for example. I’d restart to be sure though.

      • dino@discuss.tchncs.deEnglish
        2·
        4 months ago

        My server tells me a restart would be required because of:

        linux-base linux-image-6.1.0-22-amd64

        Does that have anything to do with the SSH package?

        • Kusimulkku@lemm.ee
          2·
          4 months ago

          It sounds like it’s the kernel but whether it has anything to do with ssh, I really don’t know. Sometimes parts work together in surprising ways, as I learned with the recent sshd/systemd/xz exploit.

          You might be fine and this was the most alarming exploit since it’s very inconvenient, but personally I’d restart just to be sure.

        • digdilem@lemmy.mlEnglish
          1·
          4 months ago

          No - it’s the kernel image - the actual operating system, rather than a service that runs on top of it.

          If you just want to restart your ssh service after updating the packages, then “systemctl restart sshd” is all that’s needed, although you should probably reboot whenever the package manager suggests as a general good habit.

    • fakeaustinfloyd@ttrpg.network
      3·
      4 months ago

      For anyone in RHEL / Fedora land (or using dnf somewhere else), try dnf needs-restarting to list executables that have mismatched files on disk vs memory. The -r flag will hint if a reboot is needed (due to things like kernel or glibc changes)

    • lengau@midwest.social
      1·
      4 months ago

      The packages in most distros will also restart the server for you. Any existing SSH sessions will technically be running in vulnerable versions, but if I’m understanding the vulnerability correctly this isn’t a problem, as they won’t be trying to authenticate a user.

      If you want to be sure, you can manually restart the ssh server yourself. On most distros sudo systemctl restart sshd should do it.

  • ssm@lemmy.sdf.org
    5·
    4 months ago

    Worth noting this only affects the portable release of OpenSSH, so OpenBSD (or anyone else using the native release) are unaffected.