Nach Upgrade auf 24.11 - Nessus Scan zeigt HIGH Vulnerability OpenSSH < 9.8 RCE?????
-
Hallo,
nach einem erfolgreichen Upgrade von der Version 24.03. (durchgepatcht ohne jeglich erkannte NESSUS lecks), bekomme ich jetzt, die im Betreff angezeigte Meldung auf meinem NESSUS. Anbei die Nessus Beschreibung dazu! Neue Patche für die 24.11. gibt es anscheinend noch nicht? Man soll auf OpenSSH min 9.8 Upgraden, da die Version 9.7 installiert ist! Hat jemand eine Idee?Danke,
SuttiDescription
The version of OpenSSH installed on the remote host is prior to 9.8. It is, therefore, affected by a vulnerability as referenced in the release-9.8 advisory.- This release contains fixes for two security problems, one critical and one minor. 1) Race condition in sshd(8) A critical vulnerability in sshd(8) was present in Portable OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges. Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon. Exploitation on non-glibc systems is conceivable but has not been examined. Systems that lack ASLR or users of downstream Linux distributions that have modified OpenSSH to disable per-connection ASLR re-randomisation (yes - this is a thing, no - we don't understand why) may potentially have an easier path to exploitation. OpenBSD is not vulnerable. We thank the Qualys Security Advisory Team for discovering, reporting and demonstrating exploitability of this problem, and for providing detailed feedback on additional mitigation measures. 2) Logic error in ssh(1) ObscureKeystrokeTiming In OpenSSH version 9.5 through 9.7 (inclusive), when connected to an OpenSSH server version 9.5 or later, a logic error in the ssh(1) ObscureKeystrokeTiming feature (on by default) rendered this feature ineffective - a passive observer could still detect which network packets contained real keystrokes when the countermeasure was active because both fake and real keystroke packets were being sent unconditionally. This bug was Daniel Hugenroth and Alastair Beresford of the University of Cambridge Computer Lab. Worse, the unconditional sending of both fake and real keystroke packets broke another long- standing timing attack mitigation. Since OpenSSH 2.9.9 sshd(8) has sent fake keystoke echo packets for traffic received on TTYs in echo-off mode, such as when entering a password into su(8) or sudo(8). This bug rendered these fake keystroke echoes ineffective and could allow a passive observer of a SSH session to once again detect when echo was off and obtain fairly limited timing information about keystrokes in this situation (20ms granularity by default). This additional implication of the bug was identified by Jacky Wei En Kung, Daniel Hugenroth and Alastair Beresford and we thank them for their detailed analysis.
This bug does not affect connections when ObscureKeystrokeTiming was disabled or sessions where no TTY was requested. (openssh-9.8-1)
Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.
Solution
Upgrade to OpenSSH version 9.8 or later.
See Also
https://www.openssh.com/txt/release-9.8
OutputVersion source : SSH-2.0-OpenSSH_9.7 Installed version : 9.7 Fixed version : 9.8p1 / 9.8 - This release contains fixes for two security problems, one critical and one minor. 1) Race condition in sshd(8) A critical vulnerability in sshd(8) was present in Portable OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges. Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon. Exploitation on non-glibc systems is conceivable but has not been examined. Systems that lack ASLR or users of downstream Linux distributions that have modified OpenSSH to disable per-connection ASLR re-randomisation (yes - this is a thing, no - we don't understand why) may potentially have an easier path to exploitation. OpenBSD is not vulnerable. We thank the Qualys Security Advisory Team for discovering, reporting and demonstrating exploitability of this problem, and for providing detailed feedback on additional mitigation measures. 2) Logic error in ssh(1) ObscureKeystrokeTiming In OpenSSH version 9.5 through 9.7 (inclusive), when connected to an OpenSSH server version 9.5 or later, a logic error in the ssh(1) ObscureKeystrokeTiming feature (on by default) rendered this feature ineffective - a passive observer could still detect which network packets contained real keystrokes when the countermeasure was active because both fake and real keystroke packets were being sent unconditionally. This bug was Daniel Hugenroth and Alastair Beresford of the University of Cambridge Computer Lab. Worse, the unconditional sending of both fake and real keystroke packets broke another long- standing timing attack mitigation. Since OpenSSH 2.9.9 sshd(8) has sent fake keystoke echo packets for traffic received on TTYs in echo-off mode, such as when entering a password into su(8) or sudo(8). This bug rendered these fake keystroke echoes ineffective and could allow a passive observer of a SSH session to once again detect when echo was off and obtain fairly limited timing information about keystrokes in this situation (20ms granularity by default). This additional implication of the bug was identified by Jacky Wei En Kung, Daniel Hugenroth and Alastair Beresford and we thank them for their detailed analysis.
-
Ich vermute das bezieht sich hierauf:
https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc
Das müsste dann die Sau gewesen sein, die im Juli durchs Dorf getrieben wurde, wo man meinte man hätte über ne Race Condition und irgendwelchen Wartespielchen nen Exploit in SSH gebaut. Tatsächlich hatte das auf dem Papier aber nur für irgendwelche 32bit Systeme geklappt und auch dort war es hochgradig unstabil und nicht einfach zu reproduzieren. Mit ASLR und Co war es nicht nachzuvollziehen und auf 64bit konnte bislang m.W.n. niemand erfolgreich einen Durchbruch schaffen. Auch nicht mit den Timing Geschichten. Das wurde insgesamt wieder höher gekocht als es tatsächlich in der Praxis war. Zumal im Fall von der Firewall SSH nicht unbedingt für die ganze Welt offen sein sollte.
Anyway, der genannte Fix war im Juli verfügbar und wurde bei FreeBSD 13 und 14 angewendet. pfSense Plus ist aber auf FreeBSD 15 und damit noch weiter. Es steht da zwar noch kein neueres SSH zur Verfügung, aber der Patch dafür ist in den SSH eingebacken.
Siehe: https://forum.netgate.com/topic/188992/sshd-cve-2024-6387-vulnerability
Witziger ist eher, dass dein Nessus das in 24.03 nicht gemeldet hat, in dem Thread wurde da nämlich schon zu 24.03 hingewiesen, dass es erkannt wurde. Da scheint dein Nessus Scan ziemlich zufällig zuzuschlagen? Hätte er die ganze Zeit eigentlich schon anmängeln müssen.
Cheers :)
-
Danke für Deine Antwort und unter 24.03 hat NESSUS das auch erkannt, nach Installation der aktuellem System Patches, damals im Juli/August, war der Scan ohne Fehler, insofern ist das schon eigenartig, und eher ein Rückschritt, oder? Natürlich habe ich SSH nicht am WAN geöffnet, manchmal kommt das Böse aber eben auch von intern -:)! Theoretisch!
Ich öffne jetzt SSH nur nach Bedarf, eben um gaaanz sicher zu gehen!
VG
Sutti -
@NSuttner said in Nach Upgrade auf 24.11 - Nessus Scan zeigt HIGH Vulnerability OpenSSH < 9.8 RCE?????:
und eher ein Rückschritt, oder? Natürlich habe ich SSH nicht am WAN geöffnet, manchmal kommt das Böse aber eben auch von intern -:)! Theoretisch!
Naja eher ein Rückschritt von Nessus? Denn scheinbar hat er vorher was erkannt (was auch immer?) was er jetzt nicht erkennt, denn wie du oben im Forenbeitrag siehst, ist das Paket in der 24.11 gepatcht. Die Output sagt ja auch, er weiß nicht ob das gepatcht ist oder nicht, sondern weist nur drauf hin wegen der Version. Aber Komisch dass er in 24.03 dann irgendwann Ruhe gab.
Cheers
-
I will answer this post in English because it is the most commonly used language. I am also experiencing this problem and have Nessus. It is too simple to blame Nessus because when I run the 'ssh -V' command in the Command Prompt myself, I get exactly the same result:
OpenSSH_9.7p1, OpenSSL 3.0.14 4 Jun 2024
So it's no longer a Nessus issue but a pfSense issue. OpenSSH is not updated correctly, or OpenBSD.
I am on the latest pfSense version (24.11).
Rico
-
@ricoooww Hi, that's what i meant, wrong (old) OpenSSH version in use again!! Regards, Sutti
-
@ricoooww said in Nach Upgrade auf 24.11 - Nessus Scan zeigt HIGH Vulnerability OpenSSH < 9.8 RCE?????:
I will answer this post in English because it is the most commonly used language. I am also experiencing this problem and have Nessus. It is too simple to blame Nessus because when I run the 'ssh -V' command in the Command Prompt myself, I get exactly the same result:
OpenSSH_9.7p1, OpenSSL 3.0.14 4 Jun 2024
So it's no longer a Nessus issue but a pfSense issue. OpenSSH is not updated correctly, or OpenBSD.
First, you are in the GERMAN subsection of the forums. Common language or not, this subforum is in the language of its name and NOT the general forum of pfSense so if you have a specific issue you want to address the team, please post this in General or Installation problem forum sections, NOT in a language speicific subforum!
Second, as already linked: it's irrelevant what your
ssh -Voutput shows, when nessus only checks a version string and not the vulnerability addressed. The devs have already addresses that this version of FreeBSD has a patched version of the OpenSSH binary so comparison for a version number are nonsense.It's the same BS we had with customers over and over again with stupid / too simple minded automation scanners that only check for specific vulnerable version strings but don't actually check, if the vulnerability is actually eploitable. Ubuntu/Debian for example do the exact same thing. Security patches are addressed and rolled out and while you can see the paket version being updated, the service ITSELF has the SAME versioning as before. So checking for that is simply not helpful.
If you're unsure about it being exploitable try to run the exploit locally or let your nessus install do it. If it works, I'll happily back you up to submit a Security/Bug report in pfSense Redmine for that issue!
Why it vanished with 24.03 after the system patch? Have a look at
https://forum.netgate.com/post/1175845The post shows the FreeBSD workaround that was applied at the time. It not only sets LoginGraceTime to 0 as a workaround but also disabled showing the version number to stop scans for specific SSH version strings. As that was no longer necessary in 24.11 it is now default again which shows the version and sets LoginGraceTime to 30. That's why I think it now pops up again but shows, that the scanners still do a bad job of actually checking for vulnerabilities but only compare for specific guessed vulnerable versions.
Cheers :)
-
@NSuttner said in Nach Upgrade auf 24.11 - Nessus Scan zeigt HIGH Vulnerability OpenSSH < 9.8 RCE?????:
@ricoooww Hi, that's what i meant, wrong (old) OpenSSH version in use again!! Regards, Sutti
Antworten
Das ist falsch. 24.03 hatte nicht 9.7p1, sondern 9.6p1. Da wir mehrere Versionen im Lab haben ist das einfach nachzuprüfen:
[24.03-RELEASE][admin@pfs-plus-2403.lab.test]/root: ssh -V OpenSSH_9.6p1, OpenSSL 3.0.13 24 Oct 2023 [24.11-RELEASE][admin@pfs-plus-2411.lab.test]/root: ssh -V OpenSSH_9.7p1, OpenSSL 3.0.14 4 Jun 2024Erneut: Sich NUR auf einen stumpfen Versionsvergleich bei einem Scan zu verlassen trifft keine Aussage darüber ob eine bestimmte CVE Version gepatcht wurde oder nicht.
Dafür gibt's ne CVE Übersicht, nen Audit Kommando oder andere Funktionen, mit denen ich prüfe, ob das OS an der Stelle für Paket X ein Patch Y drin hat oder nicht. Wenn ich das nicht habe oder direkt den Hersteller/Dev angehe, dann muss ich mich auch auf das Verlassen, was mir gesagt wird. Wenn ich aber hinterher hingehe und sage "glaub ich nicht" - bringt das halt wenig ;) Entweder ich belege dann durch Exploit dass es nicht gepatcht ist oder muss meinem Hersteller glauben, der sagt, dass in der neuen Version eine gepatchte SSH Version bereit steht.Nur ein Beispiel auf unserer Farm mit VMs eine Ubuntu VM:
jegr@atlanta:~$ ssh -V OpenSSH_9.6p1 Ubuntu-3ubuntu13.7, OpenSSL 3.0.13 30 Jan 2024 jegr@atlanta:~$ pro fix CVE-2024-6387 CVE-2024-6387: OpenSSH vulnerability - https://ubuntu.com/security/CVE-2024-6387 1 affected source package is installed: openssh (1/1) openssh: A fix is available in Ubuntu standard updates. The update is already installed. ✔ CVE-2024-6387 is resolved.Man siehe: gleiche angeblich "kaputte" OpenSSH Version, wurde aber gepatcht/gefixt. Trotzdem nerven solche Scanner immer noch, weil sie denken "Oh nein! Die kann gehaxxx0rt werden!"
Nein kann sie nicht.
"is resolved" heißt hier übrigens wirklich gepatcht, wäre das nicht notwendig weil Version zu alt oder nicht betroffen steht bei Ubuntu hier statt dessen "... does not affect your system". Das wird also unterschieden.Und man glaubt nicht, wie viele solche stupiden Scans inzwischen als "Security" angeboten werden ohne jegliche Einschätzung, Einstufung oder Prüfung. Da fällt dann hinten raus ein x-100 Seiten Bericht, der dann voller Zorn an den Hoster, Betreiber, Whoever geht und der (wir) müssen uns dann durch solche stumpfsinnigen Berichte wühlen und automatisiert alle CVEs abfragen und die Antworten ausgeben, damit die Leute zufrieden sind. Weil wir ja nicht genug zu tun haben.
Also sorry wenn der Ton sich vielleicht zwischendurch mal schärfer angehört hat, das ist damit nicht gemeint und nicht persönlich, aber dieses CVE-Gereite ist eine sehr unschöne Begleiterscheinung der letzten 1-2 Jahre, in denen Startups mit solchen Scannern aus dem Boden sprießen, Gelder bekommen weil ist ja für Sicherheit und dann für uns massive Zeitverschwendung generieren.
Cheers :)
