News regreSSHion: Millionen Linux-Systeme von OpenSSH-Lücke bedroht

[Y-Chromosome]

Richtig. Mit der Option bleibt überhaupt keine Zeit, sich anzumelden. Wie soll man sich denn damit anmelden können? Vielleicht kann ja der Tippgeber mehr dazu sagen.

Ist leider falsch.

Ich poste es nochmal:

login_grace_time
               Gives the grace time for clients to authenticate themselves (default 120 seconds).  If the client fails to authenticate the user within  this
               many seconds, the server disconnects and exits.  A value of zero indicates no limit.

 

[Termy]

Wie ist es eigentlich möglich, ein gepatches Problem wieder einzuführen?

Naja, eine Race Condition ist immer ein komplexes Thema. Um die "richtig" zu patchen müsste man ggf. die komplette Architektur des betroffenen Bereichs grundlegend ändern. Da das natürlich extremen Aufwand bedeuten würde wird geschaut, wie man das sonst vermeiden kann (habe jetzt keine Ahnung, wie es hier gemacht wurde, sei es über explizite Syncs, Locks oder sonstwas). Und mit 8.4 wurde dann wohl vermutlich an anderer Stelle irgend was geändert, was diesen Check umgeht oder eine Vorbedingung wird anders behandelt o.ä.

Dass solche Race Conditions schwer von automatischen Tests erfasst werden macht das natürlich noch schwerer zu vermeiden.

 

[Randnotiz]

Wie gut, dass meine Geräte von außen nur über Lösungen wie Zerotier oder Tailscale zugänglich sind.

Solche kritischen Dienste aktuell halten, sollte man trotzdem, besonders wenn man etwas wie einen VPS oder Rootserver nutzt.

Habe sowieso den Zugang auf Schlüssel beschränkt, aber trotzdem.

 

[devanet]

Puh, zum Glück noch mit Debian 11 unterwegs, damit die nicht betroffene Version 8.4 gehabt

 

[Keylan]

zum Glück noch mit Debian 11 unterwegs,

Da musste ich schon schmunzeln, als ich gelesen hatte, dass viele Debian Systeme nicht betroffen sind, weil sie die 5 Jahre alte Version von OpenSSH noch nicht eingeführt haben.

Wie ist es eigentlich möglich, ein gepatches Problem wieder einzuführen?

Weil man im Codeverlauf diverse Dinge mehrfach machen muss, aber abhängig davon unter welchen Umständen unterschiedlich implementieren muss.
Der Memory-Overflow der hier ausgenutzt wird, wird erzeugt wenn ein Alert auslöst. Also wenn eine Fehlermeldung erzeugt wird und in ein log geschrieben wird (hier im Kontext des Anmeldetimeouts)

Bei Prozessen wie Alerts muss zum teil zwischen synchroner und asynchroner Methodik gewechselt werden abhängig welche Prozesse diese Auslösen und welche Prozesse parallel noch ausführbar und ggf. priorisiert sein müssen.
Ob das hier genau dem beschriebenen Fall entspricht ist mir nicht ganz klar, aber allein das einfügen eines neuen Alerts in einem anderen Prozess, oder auch Veränderung der thread-zugehörigkeit eines Prozesses mit einem Alert kann die einmal getroffenen Maßnahmen wieder aushebeln.

Wie von @Termy erwähnt, sind die Bedingungen die zu solchen Race-Conditions in asynchronen Prozessen führen nicht nur schwer zu erkennen, sondern auch schwierig zu Testen.

 

[nazgul77]

Wie war das nochmal mit der Behauptung "Linux sei per se sicherer"?

Falscher Kontext. OpenSSH hat nichts mit Linux zu tun.
OpenSSH gibt es für so ziemlich alle Betriebssysteme.

https://learn.microsoft.com/en-us/w...ion/openssh/openssh_install_firstuse?tabs=gui

 

[lorpel]

Mich wundert es immer wieder wie Sicherheitslücken in Linux drin sein können, wo doch Milliarden Menschen den Quellcode reviewen können. Fällt sowas denn keinem auf?

 

[Kuristina]

Fällt sowas denn keinem auf?

Ist es dir aufgefallen? 🙂

 

[Simon#G]

OpenSSH gibt es für so ziemlich alle Betriebssysteme.

OpenSSH stammt vom OpenBSD Projekt, was als sehr sicher gilt. Tatsächlich ist OpenBSD auch nicht betroffen. Wirft also doch nicht das beste Licht auf Linux.

 

[Data_x33]

Ist leider falsch.

Danke für die Info. Ich habe das hier auf Heise gefunden. So astrein ist es aber auch nicht.

So können Admins die "Race Condition", die dem Angriff zugrunde liegt, beseitigen, indem sie SSH-Clients mittels "LoginGraceTime 0" in der SSH-Konfigurationsdatei (meist /etc/ssh/sshd_config) unbegrenzt viel Zeit bis zum erfolgreichen Log-in einräumen. Das Risiko dieser Einstellung ist jedoch, dass Angreifer alle verfügbaren SSH-Verbindungsmöglichkeiten des Servers belegen, die dann mangels Zeitlimit nie mehr freigegeben werden. Legitime Nutzer wären somit ausgesperrt.

 

[Keylan]

So astrein ist es aber auch nicht.

Die Idee die LoginGraceTime zu ändern ist überhaupt nicht Praktikabel. Es ist eine theoretische Maßnahme die helfen soll zu verstehen wie die Attacke überhaupt funktioniert. Eben indem man mit jedem Anmeldeversuch versucht einen Timeout zu erreichen und dabei hofft wie Ausnahmebedingung der Race-Condition zu treffen.

Kaum ein System im Netz dürfte wirklich betroffen sein, da auch ohne diesen Expoit das öffnen eines Servers zum Internet per SSH ohne weitere Sicherheitsmechanismen als grob Fahrlässig gilt.
Nahezu jedes System im Netz sichert sich gegen DDOS Attacken ab. Das allein macht den Angriffsvektor quasi dicht (die ~0,0001% Chance müsste innerhalb der ersten paar hundert Versuche glücken).

Dann ist schon vor der Veröffentlichung ein Update verfügbar gewesen, welches bereits für alle Distros zur Verfügung steht und die Lücke behebt. Bei solchen Lücken dauert es selbst bei den behäbigen Maintainern maximal 1-2 Tage eher wenige Stunden bis diese bereitgestellt sind.

 

[lynx007]

Falscher Kontext. OpenSSH hat nichts mit Linux zu tun.
OpenSSH gibt es für so ziemlich alle Betriebssysteme.

https://learn.microsoft.com/en-us/w...ion/openssh/openssh_install_firstuse?tabs=gui

Falsch! Die Sicherheitslücke betrifft in dem Fall wirklich nur Linux, aber nicht zb BSD! Ist also in diesem Fall leider wirklich schlecht formuliert. Denn doch, es hat in dem Fall bedauerlicherweise auch etwas mit Linux zu tun!

Das Problem haben z. B. Unix nicht! Wird hier gut erklärt, warum! Es ist also das zusammenspiel von OpenSSH und Linux! Dass es "nichts" mit Linux zu tun hat, ist daher falsch. Sicherheitslücken haben praktisch immer etwas mit mehrere Faktoren zu tun. Hier in diesem Fall, OpenSSH, Linux, 32 Bit...

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[Data_x33]

Kaum ein System im Netz dürfte wirklich betroffen sein, da auch ohne diesen Expoit das öffnen eines Servers zum Internet per SSH ohne weitere Sicherheitsmechanismen als grob Fahrlässig gilt.

Sprach man nicht von 14 Millionen Servern, die betroffen wären ?

 

[Helge01]

@GFdeb12 Er schrieb das kaum ein Server mit SSH Zugang in einem Netz ohne Zugriff aus dem Internet betroffen wäre.

Kritisch sind Server die öffentlich erreichbare SSH Zugänge haben, davon dürfte aber hoffentlich auch schon ein großer Teil gepatcht sein.

 

[metoer]

Falsch! Die Sicherheitslücke betrifft in dem Fall wirklich nur Linux, aber nicht zb BSD! Ist also in diesem Fall leider wirklich schlecht formuliert. Denn doch, es hat in dem Fall bedauerlicherweise auch etwas mit Linux zu tun!

Naja, auf OpenBSD ist der exploit nicht möglich, das stimmt. Andere Betriebssysteme als Linux wurden von den Entdeckern aber schlicht nicht getestet.

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.

https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

Microsoft hält es scheinbar nichtmal für nötig eine Stellungnahme rauszugeben:
https://github.com/PowerShell/Win32-OpenSSH/issues/2249

 

[andy_m4]

aber nicht zb BSD!

Kommt drauf an, welches BSD Du meinst.
OpenBSD ist nicht betroffen.
Für FreeBSD gibts aber ein Security Advisory (und einen Patch).
Auch zu NetBSD gibts ein entsprechendes Advisory.
Bei DragonflyBSD weiß ich es jetzt nicht. Aber die haben OpenSSH 9.1 drin und damit eine potentiell gefährdete Version.

 

[lynx007]

@andy_m4

Ok, stimmt, das habe ich wohl leider überlesen...

Es sind "glibc-based Linux systems" oder besser noch alle glibc-based X System?

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.

https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

 

[andy_m4]

Es sind "glibc-based Linux systems" oder besser noch alle glibc-based X System?

Also vorneweg: Ja, unter den BSDs hat man üblicherweise keine GNU libc. Die nutzen ihre jeweilig eigene libc, die ursprünglich aus den damals veröffentlichten Berkley-UNIX stammt.

Der aktuelle Stand ist wohl so, das da für für non-glibc der Angriff prinzipiell genauso denkbar ist, aber schlicht noch niemand das mal konkret untersucht hat, ob das wirklich möglich ist (außer die OpenBSD-Leute für ihr System).

 

[lynx007]

@andy_m4

Angeblich Alpin Linux, mit musl libc, mit dieser Single Händler Race Condition, nicht angreifbar sein.

Das Paper ist aber auch nen "Brett" ... Als "green-head" dahinter zu steigen, ist nicht ohne ^^

https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[lorpel]

Ist es dir aufgefallen? 🙂

Ich hatte mir Linux code mal angesehen und fand das so gruselig, dass ich dem abgeschworen habe. Daher bin ich nicht bis zu der Lücke vorgedrungen.