Nach Upgrade auf 24.11 - Nessus Scan zeigt HIGH Vulnerability OpenSSH < 9.8 RCE?????

NSuttner

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,
Sutti

Description
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
Output

  Version source    : SSH-2.0-OpenSSH_9.7
  Installed version : 9.7
  Fixed version     : 9.8p1 / 9.8

JeGr

@NSuttner

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 :)

NSuttner

@JeGr

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

JeGr

@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