OpenSSH, die Schwachstelle (CVE-2023-38408); und fehlende OpenSSL Patches in Windows sowie PowerBI

Sicherheit (Pexels, allgemeine Nutzung)[English]Ich ziehe mal ein Thema zu einem Sammelbeitrag zusammen, welches schon ein paar Tage bei mir auf der Agenda steht. Vor einigen Tagen wurde bekannt, dass es in OpenSSH die Schwachstelle CVE-2023-38408 gibt. Während die IT nun auf Patches wartet, (in Linux gibt es wohl Update) stellt sich ein zweites Thema: nämlich die  Aktualisierung von OpenSSL und Windows und bei der Microsoft-Lösung PowerBI.


Anzeige

Zuerst einige Begriffserklärungen. OpenSSL ist eine freie Software zur Absicherung von Verbindungen für die Transport Layer Security und umfasst Implementierungen der Netzwerkprotokolle und verschiedener Verschlüsselungen. Zudem gibt  es das Programm openssl für die Kommandozeile zum Beantragen, Erzeugen und Verwalten von Zertifikaten. Die in C geschriebene Basisbibliothek stellt allgemeine kryptographische Funktionen zum Ver- und Entschlüsseln sowie diverse weitere Werkzeuge bereit. In OpenSSL werden aber immer wieder Schwachstellen öffentlich – einige Artikel werden hier im Blog bei einer Suche nach dem Begriff ausgeworfen.

OpenSSH ist dagegen ein Programmpaket zur Dateiübertragung. Dazu nutzt es Secure Shell inklusive SSH File Transfer Protocol und beinhaltet dafür Clients, Dienstprogramme und einen Server.

Erst im Februar 2023 wurden in OpenSSH 9.2 wurde zwei Sicherheitsprobleme behoben (siehe mein Blog-Beitrag Nachlese zu Sicherheitslücken und Patches (6. Feb. 2023)).

OpenSSH Schwachstelle CVE-2023-38408

Laut NIST-Beitrag vom 22. Juli 2023  gibt es in der PKCS#11-Funktion im ssh-agent in OpenSSH vor 9.3p2 die Schwachstelle CVE-2023-38408. Ein nicht ausreichend vertrauenswürdigen Suchpfad kann zu einer Remote Code-Ausführung führen. Dieses Problem besteht aufgrund einer unvollständigen Korrektur für CVE-2016-10009. Yair Divinsky von vulcan.io hat zum 20. Juli 2023 im Beitrag How to fix CVE-2023-38408 in OpenSSH auf das Thema hingewiesen. Wäre womöglich an mir vorbei gegangen, wenn nicht dieser Kommentar hier im Blog hinterlassen worden wäre.

Jetzt müssen unsere Linux-Freunde mal wieder stark sein, nachdem es letzte Woche eines der Vorzeigeprojekte "Ghostscript" getroffen hat, ist jetzt das sehr sicherheitsrelevante OpenSSH, an dem die Besten der Besten programmieren, und JEDER in den Quellcode reinschauen kann, und das z.B. auch bei SFTP für öffentlich zugängliche Server eine außerordentlich wichtige Rolle spielt, vom BSI mit einem Score von 8.1 für die grandiose Leistung CVE-2023-38408 auf Sicherheitskala bedacht worden. Gratuliere! Patches gibts derzeit wahrscheinlich nur für OpenSSH 9 (9.3p2), aber da die Lücke in einer offensichtlich fehlerhaften Sicherheitskorrektur von OpenSSH 7 CVE-2016-10009 steckt, werden wohl auch zu 7 und 8 Backports nötig sein.

Und wie man leicht anhand der CVE-Nummern ausrechnen kann, war die Lücke auch nur unkritische 7 Jahre offen.

Gibt noch Folgekommentare mit dem Hinweis, dass die Schwachstelle nur relevant ist, wenn der sh-pkcs11-Helper (z.B. bei Smartcards und Tokens) verwendet wird. Ergänzung: Gerade gesehen, dass The Hacker News die obige Schwachstelle und die Aufforderung zum Patchen von Linux-Systemen aktuell in diesem Artikel angesprochen hat.

OpenSLL in der Microsoft Welt

In diesem Kontext fällt mir noch das Thema OpenSSL unter Windows und in Microsoft-Produkten ein. Aber wie steht es um die Aktualisierung in der Windows-Welt? Alles, was Open Source-Software, gepflegt durch Microsoft, betrifft, verursacht bei mir irgendwie Unwohlsein. Ich ziehe daher mal die zwei Fundsplitter hier zusammen, die zu OpenSSL im Hinterkopf schlummern.

OpenSSL-Schwachstellen in Microsoft PowerBI Desktop wird nicht gefixt

Zum 21. Juli 2023 hat mich ein Blog Leser-Klaus per E-Mail kontaktiert, um auf ein spezielles Thema im Kontext OpenSLL hinzuweisen. Das geht um die Software Microsoft PowerBI Desktop, eine Software, mit der sich Unternehmensdaten in visuellen Berichten darstellen lassen. Tools sollten Nutzern auch ohne Programmierkenntnisse ermöglichen, individuelle Auswertungen zu erstellen. Der Leser schrieb dazu:

Hallo,

ich habe mal wieder etwas Interessantes.

Das Produkt nennt sich „Microsoft PowerBI Desktop" und wird über den Microsoft Store verteilt/heruntergeladen.

Für „Open SSL" gibt es eine Reihe CVE's. Unter „Microsoft 365 Defender" wird Open SSL wegen der CVE's als Sicherheitsempfehlung gemeldet.

Der Leser hatte nachfolgenden Screenshot mit den Sicherheitsempfehlungen des Defender mitgeschickt (auf den Screenshot klicken, um das Bild zu vergrößern).


Anzeige

OpenSSL-Schwachstellen in Windows

Es werden also eine ganze Reihe bekannter Schwachstellen in OpenSSL ausgewiesen, die dort nicht geschlossen wurden. Der Leser schrieb mir dazu:

Als ich mir das genau angesehen habe, durfte ich feststellen, dass die Geräte gar kein Openssl installiert haben, sondern sich die Meldung auf "Microsoft PowerBI Desktop" beziehen, das offensichtlich Bibliotheken von Openssl verwendet.

Hier wäre Microsoft in der Pflicht was zu tun. Macht Microsoft aber nicht, wenn man mal auf das Datum der CVE's achtet.

Vielleicht einen Beitrag wert?

Das Thema habe ich nun hiermit im Blog öffentlich gemacht. Für mich war das aber nichts wirklich neues, auch wenn mir der obige Sachverhalt konkret unbekannt war. Aber ich hatte im Beitrag IT-Sicherheit: Alles kaputt? mal erwähnt, dass man PowerBI nicht mal mit der Kneifzange anfassen solle.

OpenSLL und Updates durch Microsoft

Zudem liegt mir das Thema OpenSSL und die Aktualisierung durch Microsoft noch an einer anderen Stelle "im Magen". Es gibt den Beitrag Windows 10 und die OneDrive-Sicherheitslücken – Teil 3 aus dem Jahr 2018, wo ich Erkenntnisse von Stefan Kanthak in Bezug auf "langsames patchen von OpenSSL-Schwachstellen durch Microsoft" in ihrer Software thematisiert hatte.

Von der cURL-Bibliothek ist bekannt, dass Microsoft sich da unendlich Zeit mit dem Patchen von Schwachstellen lässt – siehe meine Blog-Beiträge Windows: Microsoft liefert cURL-Bibliothek weiterhin mit Schwachstellen aus (Feb. 2023) und Windows und die cURL-Falle; gelöschte Curl-Instanz macht Windows-Update kaputt).

Im Kontext dieser Beiträge hatte Stefan Kanthak mich im März 2023 angeschrieben und erneut darauf hingewiesen, dass Microsoft mit dem Schließen von OpenSSL-Schwachstellen auf dem Kriegsfuß steht. Nebenbei merkte er an, dass "auch ICU (IBMs "International Components for Unicode") IMMER total veraltet ist", was hat leider außer ihm noch niemand bemeckert habe. Im Kontext des obigen Themas geht es aber um OpenSSL und Stefan Kanthak wies auf diesen Kommentar hier im Blog hin:

Hallo zusammen,

anscheinend patcht Microsoft auch bei seinem OpenSSH-Feature in der Windows Servervariante nicht sauber über Windows Update.

Die OpenSSH-Version und die LibreSSL-Bibliothek haben auch schon einige Tage hinter sich.

Windows Server 2022 (Microsoft Windows [Version 10.0.20348.1547])
PS C:\> ssh -v localhost
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

Windows Server 2019 (Microsoft Windows [Version 10.0.17763.4010])
PS C:\ > ssh -v localhost
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

Blog-Leser M.D. bestätigt in diesem Kommentar vom 21. Juli 2023, dass bei ihm ebenfalls OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2 angezeigt wird. Ich habe mal auf die Schnelle in der Windows Eingabeaufforderung auf einem gepatchten Windows 10 2019 IoT LTSC mit den oben angegebenen ssh-Befehlen geprüft, welches OpenSSH-Version installiert ist. Es hat sich an den Versionsnummern nichts geändert, es wird die Version OpenSSH_for_Windows_7.7p1 angezeigt.  Bereits im Juli 2020 fragt jemand auf Github, warum Windows 10 20H1 immer noch mit OpenSSH 7.7p1 ausgeliefert werde. Vielleicht mal das Thema im Auge behalten – oder sehe ich das mit dem Aktualisieren von OpenSSH etwas zu kritisch?


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Software, Windows abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

17 Antworten zu OpenSSH, die Schwachstelle (CVE-2023-38408); und fehlende OpenSSL Patches in Windows sowie PowerBI

  1. 1ST1 sagt:

    OpenSSH ist nicht gleichzusetzen mit OpenSSL! Das eine hat mit dem anderen was diese Lücke angeht nur wenig bis garnichts zu tun. OpenSSL darf aber gerne auch mal in Windows aktualisiert werden, da hat SK aber schon recht.

    Für OpenSSH 7 und 8 hat übrigens bisher immer noch keine Linux-Distribution ein Update veröffentlicht. Und die meisten Distributionen, auch Debian und Ubuntu, verwenden noch die 8er Version, also Scheunentor immer noch offen. Für SLES ist aber was angekündigt, die anderen sind aber wohl noch am untersuchen oder coden.

    Einschätzung anhand jüngster Details:

    1. https://www.openssh.com/releasenotes.html

    "Exploitation can also be prevented by starting ssh-agent(1) with an
    empty PKCS#11/FIDO allowlist (ssh-agent -P ") or by configuring
    an allowlist that contains only specific provider libraries."

    Es gibt also etwas, was man ohne Updates schonmal dagegen tun kann. Das ist aber keine Mitigation, die jeder User hin bekommt (also auf Linux-Seite "Mausschubser" wie mich), fällt also grob unter die Kategorie "Frickeln".

    2. https://packetstormsecurity.com/files/173661/OpenSSH-Forwarded-SSH-Agent-Remote-Code-Execution.html

    "Originally, the path of a shared library to be loaded in
    ssh-pkcs11-helper was not filtered at all by ssh-agent, but in 2016 an
    allow-list was added ("/usr/lib*/*,/usr/local/lib*/*" by default) in
    response to CVE-2016-10009, which was published by Jann Horn (at
    :

    – if an attacker had access to the server where Alice's ssh-agent is
    forwarded to, and had an unprivileged access to Alice's workstation,
    then this attacker could store a malicious shared library in /tmp on
    Alice's workstation and execute it with Alice's privileges (via her
    forwarded ssh-agent) — a mild form of Local Privilege Escalation;

    – if the attacker had only access to the server where Alice's ssh-agent
    is forwarded to, but could somehow store a malicious shared library
    somewhere on Alice's workstation (without access to her workstation),
    then this attacker could remotely execute this shared library (via
    Alice's forwarded ssh-agent) — a mild form of Remote Code Execution.
    "

    Für mich sieht das so aus: Der Angreifer lauert auf einem manipulierten SSH-Server, das kann einer mit Remoteshell-Zugang oder evtl. auch ein SFTP-Server sein, bei letzterem bin ich mir aber nicht sicher. Alice verbindet sich per OpenSSH (oder SFTP) mit dem Server. Der Angreifer kann nun auf Alices Workstation im Temp-Verzeichnis Code ablegen und mit den Rechten von Alice ausführen. Er kann also alles machen, was Alice auch kann, auch einfache Benutzer haben schon Schreibrechte im User-Profil, in Temp und ggf. in gemounteten Netzlaufwerken oder lokal gemeinsam benutzten Datenverzeichnissen. Das kann man dann alles schonmal klauen, verschlüsseln und löschen, was schonmal schlimm genug sein kann. Man denke auch an User-Startup-Scripte, in die er weitere Dienste für sich starten kann, eine Reverseshell, was weiß ich. Außerdem kann er schonmal z.B. per (vorinstalliertem) nmap das lokale Netzwerk ausspionieren und so weitere Angriffspunkte finden "Living Off the Land Attacks (LOTL)". Er kann natürlich auch einen Bloodhound ablegen und im Userkontext starten, oder was so Seiten wie kitploit sonst so an interessanten Werkzeugen anpreisen. Kann der Angreifer über irgendeine noch nicht bekannte/gepatchte andere Lücke sich Root-Rechte verschaffen, so kann er darüber hinaus auch weiteren Schaden anrichten.

    Da der Quellcode von OpenSSL offen ist, hätte jeder Mitleser hier in den letzten 7 Jahren den Fehler bereits finden können und einen Patch dafür einreichen können. Ich denke mal, diesem Nadelstich kann kein Linux-Fanboy hier wiederprechen, oder?

    • Günter Born sagt:

      Stimmt – ich habe das noch etwas mehr herausgearbeitet – aber das Thema OpenSSL ist unter Windows /PowerBI imho unschön.

      • M.D. sagt:

        Zumal es da zwischen Linux und Windows — wahrscheinlich — noch einen gehörigen Unterschied gibt: Die OpenSSH-Versionen unter Linux mögen häufig veraltet sein, jedenfalls laut Versionsnummern, aber die Linux-Distributoren pflegen oft neue Patches in alte Versionen ein! Zumindest für SUSE Leap (15.4) wird als Standard-Version die 8.4p1 ausgegeben, die hat aber den Patch für den Agent-Bug bekommen. Die aktuellen Binaries sind vom 21. Juli dieses Jahres. Die anderen Distributionen machen das in der Regel genau so. Aus Kompatibilitätsgründen scheint es sinnvoller zu sein, die alten ABIs/APIs zu behalten und wenigstens aktuelle Sicherheits-Bugfixes zurück zu portieren.

        Microsoft scheint das, wenn überhaupt, eher seltener zu machen. Die Binaries der OpenSSH dort sind, wie beim anderen Beitrag erwähnt, deutlich älter, allerdings immer noch nicht so alt wie der originale Quellcode der zu Grunde liegenden Version. Vielleicht haben sie den einen oder anderen Fix zurück portiert. Das lässt sich aber ohne den zugehörigen Quellcode oder Debug-Sessions schwer beurteilen.

        Man kann natürlich auch unter SUSE Leap manuell auf die neueste Version upgraden, das dürfte aber wegen Abhängigkeiten eine größere Upgrade-Runde bedeuten. Und für Bleeding Edge gibt es ohnehin SUSE Tumbleweed.

    • Ralle sagt:

      Also bei meinem Debian stable ist die Version 9.2p1-2 in den Paketquellen gelistet?! Also nicht die Version 8, wie oben erwähnt.

    • Anonymous sagt:

      Wenn die "Besten der Besten" an sowas gearbeitet haben, braucht es vielleicht *noch* Bessere, die Fehler finden oder missbrauchen können? Es ist daher doch eher so, dass sich 7 Jahre kein Besserer gefunden zu haben scheint – was die CVE auch nicht besser, aber nun doch endlich öffentlich macht.

      Ich gehöre hier nicht zu den Besten, könnte da sicherlich nichts anderes finden, als Kommafehler in den Kommentaren.

  2. Robert sagt:

    Also das SSH-Szenario greift doch nur, wenn man ssh-agent zum Forwarden nutzt, oder? …noch dazu auf ein attacker-controlled-system – dann hat man sowieso ein Problem.

    Finde daher CVE-2023-38408 jetzt nicht ganz so problematisch.

  3. ich sagt:

    Replace OpenSLL with OpenSSL. :)

  4. Jan sagt:

    Wir wurden in den letzten Tagen über den SSL Port angegriffen! Lies sich auf folgende Länder zurückverfolgen USA, China und Indien (heisst nicht das die Angreifer daher kamen aber die IPs wurden benutzt).
    Die Angriffe gingen ins leere da unsere Firewall das schon geblockt hat und wir eh kein SSL VPN benutzen (Wireguard for the win).
    Zeigt aber sobald eine Schwachstelle bekannt wird, wird diese auch massiv angegriffen.
    Hier nochmal ein Aufruf an alle Ihre System abzuhärten und sich gebenfalls proffesionelle Hilfe dabei holen.

    • Anonymous sagt:

      Der Kommentar ervibt für mich kaum Sinn. Tagtäglich prasseln auf Webserver die zahlreichen Angriffsversuche ein. Port 443 usw. oder OpenSSL steht damit aber nicht direkt im Zusammenhang. Ist doch besser als Port 80 für Datenverkehr zwischen Systemen.

      OpenSSH (Secure Shell) hat icht viel mit Transporz Layer Security (TLS) oder Secure Socket Layer (SSL) zu tun. SSH ist ein anderes Protokoll und wird in der Regel über Port 22 genutzt.

  5. der bug ist das ziel sagt:

    warum wird hier in einem blogpost von openSSL und openSSH projekt gesprochen? das sind zwei grundverschiedene projekte.

    • Günter Born sagt:

      Es ist als Sammelbeitrag angegeben – das mache ich gerne, wenn vorab unklar ist, wie umfangreich ein Thema wird. Weiterhin sollte inzwischen hinreichend klar sein, dass es wirklich zwei verschiedene Projekte sind – die Gemeinsamkeit: wie schnell wird Open Source bei Schwachstellen gepatcht, wenn sie in Linux oder unter Windows bzw. in MS Software vorkommen.

  6. 1ST1 sagt:

    Ubuntu hat heute Nacht ein paar Patches heraus gebracht, aber noch nicht für alle Versionen, die noch unterstützt werden. Die anderen Distributionen werden sicher bald nachziehen.

    Die bei Heise.de erwähnte Einstufung von 8.1 (von 10) des BSI für diese Lücke war wohl auch etwas zu heiß gekocht. Ubuntu gibt dem gerade mal 5.5.

  7. Chris sagt:

    SuSe hat am 24.Juli openssh 7 und 8 gepatcht (TID war vom 20.Juli)
    https://www.suse.com/security/cve/CVE-2023-38408.html

    Geht doch flott.
    Aber es ist ein komplexes Angriffsszenario bei dem der Angreifer schon eingedrungen sein muß. Also nicht kritisch, wenn nicht ohnehin schon was passiert ist.

    Warum MS da mit Patches vor sich hin schläft, ist allerdings ein kritikwürdiger Punkt

  8. Fabian Niesen sagt:

    Nicht nur bei OpenSSH wird bei den Abhänigkeiten "etwas"geschludert. Generell sind verschiedene Produkte betroffen die nicht im Cloud-Fokus sind. Zum Beispiel auch der WSUS, da sind auch für bestimmte Funktionen einige Abhänigkeiten EOL und nicht mehr supportet. Ich hatte das mal in einem Blog-Beitrag aufgearbeitet: https://www.infrastrukturhelden.de/microsoft-infrastruktur/microsoft-windows/server/windows-server-2022/windows-server-update-service-wsus-reporting/

    Gruß
    Fabian

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.