Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    sshd CVE-2024-6387 vulnerability

    Scheduled Pinned Locked Moved General pfSense Questions
    12 Posts 5 Posters 3.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • JonathanLeeJ
      JonathanLee
      last edited by JonathanLee

      attackers would still need ssh and port 22 open on the wan connection enabled.

      Note

      "Because the malloc of this Ubuntu's glibc is already hardened against
      the old unlink() technique, we decided to transform our arbitrary free()
      into the Malloc Maleficarum's House of Mind (fastbin version): we free()
      our own NON_MAIN_ARENA chunk, point our fake arena to sshd's .got.plt
      (this Ubuntu's sshd has ASLR but not PIE), and overwrite _exit()'s entry
      with the address of our shellcode in the heap (this Ubuntu's heap is
      still executable by default). For more information on the Malloc
      Maleficarum: ..."

      pfSense utilizes FreeBSD or OpenBSD and not Ubuntu

      SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, from 2005)

      SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, from 2006)

      SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 (Debian 12.5.0, from 2024)

      None of the underline Operating Systems are FreeBSD based that are shown in this reports details. Do you know if this was also attempted in FreeBSD?

      @stephenw10 Have you looked at this let? I mean how can this interrupt freeBSD if the system has PHP limits and all the other memory hardening already built into FreeBSD and OpenBSD? This looks to be specific to Ubuntu and Debian

      Make sure to upvote

      M 1 Reply Last reply Reply Quote 0
      • M
        marcg @JonathanLee
        last edited by

        @JonathanLee , no idea as to the other OSs that were tested, although OpenBSD seems to be immune. Hoping that the pfSense devs will chime in.

        Guessing that the vulnerability exists from the LAN side as well. Blocking ssh from the WAN is a good start, but not complete protection in that case.

        JonathanLeeJ 1 Reply Last reply Reply Quote 1
        • JonathanLeeJ
          JonathanLee @marcg
          last edited by

          @marcg I see it I was searching for FreeBSD

          "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."

          Make sure to upvote

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Theoretically. See: https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc
            Workaround patch incoming.

            M JonathanLeeJ 2 Replies Last reply Reply Quote 2
            • M
              marcg @stephenw10
              last edited by

              @stephenw10, thanks.

              1 Reply Last reply Reply Quote 0
              • JonathanLeeJ
                JonathanLee @stephenw10
                last edited by

                @stephenw10

                Workaround

                If sshd(8) cannot be updated, this signal handler race condition can be
                mitigated by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and
                restarting sshd(8). This makes sshd(8) vulnerable to a denial of service
                (the exhaustion of all MaxStartups connections), but makes it safe from the
                remote code execution presented in this advisory.

                Is this the recommendation for older versions of pfSense currently?

                Make sure to upvote

                1 Reply Last reply Reply Quote 1
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Yes, the patch will set that.

                  S 1 Reply Last reply Reply Quote 1
                  • S
                    slu @stephenw10
                    last edited by

                    And the patch is already there, good work Netgate!

                    pfSense Gold subscription

                    1 Reply Last reply Reply Quote 1
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      See: https://forum.netgate.com/topic/189010/netgate-security-advisory-cve-2024-6387

                      T 1 Reply Last reply Reply Quote 1
                      • T
                        tedquade @stephenw10
                        last edited by

                        @stephenw10 Will a fix for this be incorporated in the next 24.09-Development release?

                        Ted

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          Yes 24.08 will have an updated openssh version.

                          1 Reply Last reply Reply Quote 2
                          • JeGrJ JeGr referenced this topic on
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.