• OsrsNeedsF2P@lemmy.ml
    link
    fedilink
    arrow-up
    80
    ·
    4 months ago

    They have named this vulnerability “regreSSHion”, since it represents the re-emergence of a bug that was previously patched in 2006

    That’s a great name

  • treadful@lemmy.zip
    link
    fedilink
    English
    arrow-up
    54
    ·
    4 months ago

    The new vulnerability, assigned CVE-2024-6387, allows for unauthenticated remote code execution (RCE) with root privileges, posing a severe threat to affected systems.

    Oh, fuck. Guess this is my day now.

  • mumblerfish@lemmy.world
    link
    fedilink
    arrow-up
    37
    ·
    4 months ago

    If I’m not mistaken, it seems like this is a timing attack and you need a lot of attack attempts to make it work. If you have like a fail2ban rule for ssh it should mitigate this attack to quite some degree, right? (Of course updating would still be the best).

  • schizo@forum.uncomfortable.business
    link
    fedilink
    English
    arrow-up
    33
    ·
    4 months ago

    Looks like Debian and Ubuntu have shipped patches, but I’m not seeing them show up in the RHEL-derivatives just yet, but I’m sure that’ll be soon™.

  • lurklurk@lemmy.world
    link
    fedilink
    arrow-up
    28
    arrow-down
    1
    ·
    4 months ago

    the in depth technical details

    TL;DR; sigalarm handler calls syslog which isn’t safe to call from a signal handler context.

    Their example exploit needed about 10k attempts to get a remote shell so it’s not fast or quiet, but a neat find regardless

    • bitfucker@programming.dev
      link
      fedilink
      arrow-up
      5
      ·
      4 months ago

      I can already imagine the log generated will be a hint. We usually automate those anyway as it is closer to (D)DoS too.

  • namingthingsiseasy@programming.dev
    link
    fedilink
    arrow-up
    22
    ·
    4 months ago

    The full write-up can be found here and should be fairly readable for users of this forum.

    Some quotes that I thought were interesting:

    With a heap corruption as a primitive, two FILE structures malloc()ated in the heap, and 21 fixed bits in the glibc’s addresses, we believe that this signal handler race condition is exploitable on amd64 (probably not in ~6-8 hours, but hopefully in less than a week). Only time will tell.

    So 64-bit systems seem to be a bit more resistant to this it seems? But I can’t be completely sure given how much I’ve read about this yet.

    This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd’s privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

    It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).

    And OpenBSD wins again it seems.

    • Killing_Spark@feddit.de
      link
      fedilink
      arrow-up
      5
      ·
      4 months ago

      Yeah they were experimenting with 64bit exploitation when this signal handler got some focus regarding a (likely related) deadlock so they rushed to disclose their findings to the project to minimise the possibility of having eyes on this vulnerability

  • Lung@lemmy.world
    link
    fedilink
    arrow-up
    24
    arrow-down
    2
    ·
    4 months ago

    It’s shit like this that makes me convinced that governments can easily hack into pretty much every system

    • NotMyOldRedditName@lemmy.world
      link
      fedilink
      arrow-up
      12
      ·
      4 months ago

      I mean, on TV every character seems to be able to hack any system in a few seconds.

      They clearly must have done some research by watching some NSA hackers who can hack every system.

    • Mike1576218@lemmy.ml
      link
      fedilink
      arrow-up
      9
      ·
      4 months ago

      They probably can. jut every hack done has the possibility of spoiling the exploit. A good exploit can cost a million $. So if hacking you is worth more then say 100k to them, you’re in trouble. Otherwise they will only target you with everyday surveilance.

      • Lung@lemmy.world
        link
        fedilink
        arrow-up
        7
        ·
        4 months ago

        That’s a spooky one. From first glance - 500 employees and zero click takeovers of phones? Yikes. Makes me want to not have a phone… Ofc Google/Apple/USA have had this capacity for ages

          • scrion@lemmy.world
            link
            fedilink
            arrow-up
            6
            ·
            edit-2
            4 months ago

            Yes, targeted attacks like that definitely exist, most famously maybe the most recent social pressure to merge a vulnerability to the xz library by actor “Jia Tan”:

            https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

            This started a whole discussion about relying on (often unpaid) volunteer work for critical systems and the pressure and negativity these people face, which is a discussion that was absolutely needed, and which we are still lightyears away from fixing.

            Currently, open source is still treated like this: https://trac.ffmpeg.org/ticket/10341

            (I can only recommend reading the whole story around this issue, which boils down to Microsoft admitting they rely on an open source project for something they consider critical to their customers, but not willing to pay the maintainer a bounty for fixing the issue)

      • teawrecks@sopuli.xyz
        link
        fedilink
        arrow-up
        6
        ·
        4 months ago

        The NSA is doubtless sitting on a trove of these types of vulnerabilities to use when they really need access to something.

  • IntentionallyAnon@lemm.ee
    link
    fedilink
    arrow-up
    18
    arrow-down
    1
    ·
    4 months ago

    Good thing I’m on vacation for the next week and have my PC turned off. Remind me to update on Saturday

  • Venia Silente@lemm.ee
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    2
    ·
    4 months ago

    The fun thing about regressions: these things affects you if your system is new enough that it has the behaviour reintroduced. Which means you are less likely to be hit if you are using Debian Stable (or even Oldstable) than, say, Sid (unpatched at the time of writing this comment) or Arch btw.

    • Gurfaild@feddit.de
      link
      fedilink
      arrow-up
      3
      ·
      4 months ago

      My OpenMediaVault machine (based on Debian Oldstable) uses OpenSSH 8.4p1, so it’s old enough not to have the bug

  • I set up a wireguard VPN network between my computers and servers, and then firewalled off all services except Wireguard, and a few services on one server. That one server is my weak point, but even it has sshd firewalled off except through the Wireguard subnet.

    It’s stupidly easy to set up WG subnetworks. I’m not a networking guy, and it was trivial for me to do. If u can run an ssh server, you can set up a Wireguard subnet: just do it.

    • Creat@discuss.tchncs.de
      link
      fedilink
      arrow-up
      8
      ·
      4 months ago

      Yeah. Some services you kinda want accessible directly, but ssh really isn’t one of them. Even though it should be safe, as that’s it’s intended purpose, putting a VPN in front of it makes a lot of sense, especially with how easy it is to setup these days. Anything used for administration is systems should be behind one.

      • Wireguard really changed the landscape, for me, and my entire approach to networking. Suddenly, VPNs became fast and easy, and where previously impractical for casual (hobbyist) admins, it made creating enterprise-grade secure subnets easy. It’s astonishingly stable and reliable, such that my initial concerns about cutting off all access except through the VPN - once a truly nerve-wracking concept - is now a no-brainer. It’s made my network administration easier and more secure. My firewalls are simpler.

        Wireguard is one of the biggest high-impact, low-visibility networking game changers I’ve seen in decades.

      • machineunlearning@lemmy.ca
        link
        fedilink
        arrow-up
        5
        ·
        4 months ago

        There is definitely a shift away from traditional VPNs these days since VPN tunnels tend to be more open and permissive. You can obviously secure a tunnel and limit network access, but you are still directly accessing the networks and resources that you do allow, remotely.

        I was running Kasm for a while and I really liked this approach to secure remote access. I could effectively spin up a Ubuntu docker image and access it remotely through the browser. Secured the web portal with my IdP which requires MFA and I would login remotely and launch various apps and desktops.

        They are non persistent in nature, so once you log off and destroy the instance you would effectively get a new desktop the next login.

        Generally works pretty well

  • Possibly linux@lemmy.zip
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    3
    ·
    edit-2
    4 months ago

    Maybe it is time to move to something new

    Also why does sshd run as root. I deal like ssh could use some least privilege

    • frezik@midwest.social
      link
      fedilink
      arrow-up
      10
      ·
      edit-2
      4 months ago

      When you log in to an ssh terminal for a shell, it has to launch the shell process as the desired user. Needs to be root to do that.

      SSH has been around a long time. It’s not perfect, but it’s mostly validated. Anything new won’t have that history.

      • Possibly linux@lemmy.zip
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 months ago

        Can’t it use built in OS mechanisms for that? Surely you could figure out a way to only give it permissions it needs. Maybe break it up into two separate processes.

        • Sethayy@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          4 months ago

          That just sounds like root with extra steps (trying to implement OS security policies in a remote terminal utility)

    • Mio@feddit.nu
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      Root because it use port 22. I think anything lower than port 1024 requires it. But if this is true, then you can try change the port it is listening to something higher than that.