Linux am Dienstag: Programm für den 13.2.2024

Auch wenn ich krank bin und eher moralische Unterstützung liefere, haben wir zwei Linux Vorträge für Euch, eigentlich drei, aber der Dritte ist so spezifisch, das könnte schwer verständlich sein.

Linux am Dienstag: Programm für den 13.2.2024

u.a. im Programm am 13.2.2024, ab 19 Uhr:

Vortrag – Probleme mit Sicherheitsupdates bei Fedora. (Matthias)
Vortrag – SystemD-Utilities in freier Wildbahn. Wie man Container von außen konfiguriert. (Matthias)
Sicherheit – AnyDesk gehackt.. aber seit wann eigentlich?
Sicherheit – Ivanti schon wieder gehackt.
Linux – Kernel-Debug-API uprobes kann u.a. TLS Inhalte abschnorcheln

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

Schon wieder verpatztes Notfallupdate bei Fedora: ClamAV 1.05

Schon wieder verpatztes Notfallupdate bei Fedora: ClamAV 1.05

Ich begnüge mich mal mit der Kurzfassung:

Am 7.2. kam ein SecurityPatch auf ClamAV 1.05, das ist die ältere Linie, raus, der 2 CVEs patched, die Remote ausgenutzt werden können: https://blog.clamav.net/2023/11/clamav-130-122-105-released.html

Das Update wurde auch zeitnah vom Maintainer gebaut, aber dummerweise nicht ins Stable gepusht 🙁 Das erinnert natürlich an die OpenSSH Release vor ein paar Tagen, Ihr erinnert Euch. Keine gute Quote für das Fedoraprojekt.

Das Update

Natürlich habe ich den Maintainer schon freundlich angemault, wer von Hand updaten will, kann das so machen:

sudo dnf update clamav –enablerepo=updates-testing -y

Der Gag

In der deutschen Bloggerlandschaft gibt es ja ein sehr aktives Blog, das sehr oft die Frage der Existenzberechtigung einer bestimmten Bundesbehörde stellt. Lieber Fefe, die machen z.B. das hier:

Sehr geehrte Damen und Herren,

im Rahmen der täglichen Lagebeobachtung hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) Kenntnis über Schwachstellen in der Virenschutz-Lösung ClamAV erlangt.
Demnach könnte es einem Angreifer gelingen, aus der Ferne einen Pufferüberlauf und somit einen Softwareabsturz zu erzwingen (CVE-2024-20290). Weiterhin besteht die Gefahr einer Command Injection-Schwachstelle (CVE-2024-20328), die ClamAV selbst als „kritisch“ bezeichnet.

Inzwischen hat das BSI verwundbare Systeme in Deutschland identifiziert, die sich in Ihrem Zuständigkeitsbereich befinden. Konkret geht es um folgende IPs/URLs:
********* entfernt *********** ( zwar erreichbar, aber lehnt alles aus fremden Netzen ab )

Wir bitten Sie, den Sachverhalt zu prüfen und ggf. kurzfristig Schutzmaßnahmen einzuleiten, um Schaden zu verhindern.
Hinweise zur Absicherung können Sie zum Beispiel den Herstellerinformationen entnehmen:
https://blog.clamav.net/2023/11/clamav-130-122-105-released.html

Mit freundlichen Grüßen
das Team CERT-Bund

Im Auftrag
Till Kleinert

Bundesamt für Sicherheit in der Informationstechnik (BSI)
CERT-Bund
Godesberger Allee 87
53175 Bonn

Ohne das BSI wäre das Update zwar auch gekommen, aber vielleicht zu spät. Also danke, daß Ihr uns kontaktiert habt.

UPDATE 10:12 Uhr

Dank der Hilfe eines Unbekannten konnte ich das Update selbst ins Stable pushen (legal 🙂 ). Das Update kommt für jetzt.
Ich sollte mich langsam mal vom Projekt als inoffizielle Mitarbeiter bezahlen lassen 😉

Fedora 38 und OpenSSH’s CVE-2023-28531

Es läuft nicht immer alles glatt, aber die selbst auferlegte Quarantäne ist abgelaufen, Zeit über CVE-2023-28531 zu berichten.

Fedora 38 und OpenSSH’s CVE-2023-28531

Vor einigen Wochen wurde ein Security Audit vom Server gemacht, naja, was manche Leute so als Audit bezeichnen. In Wahrheit war es wohl nicht mehr als ein Portscan + notieren der präsentierten Versionsnummern, man hat es uns nicht genau gesagt. Jedenfalls fiel dem Scanner auf, daß OpenSSH sich mit 9.0p1 meldet, welches diverse Sicherheitslücken enthalten würde, wären da keine Backportfixe gemacht worden. Nur leider konnten wir nicht nachweisen, daß CVE-2023-28531 gefixt wurde, eine Lücke im ssh-agent von OpenSSH. Die kann man aber nur ausnutzen, wenn auch ein SSH-Agent läuft, der dafür empfänglich ist und man dem einen präparierten Schlüssel unterjubeln kann. Eine Menge Wenns, die alle „negative“ waren, da gar kein ssh-agent im Einsatz ist. Der Patch zu CVE-2023-28531 war beim Maintainerteam von Fedora einfach durchgerutscht.

Da meinten die Auditoren, daß es nicht hinnehmbar wäre, daß es eine Lücke gibt, die man nicht ausnutzen kann, weil die ja trotzdem da wäre. Findet den Fehler 😉

Der Auftraggeber legte dann noch eins drauf mit der Feststellung, daß es nicht hinnehmbar wäre, daß ein Scanprogramm bei Ihrem Webserver Alarm schlägt, selbst wenn keine Lücke drin wäre. Bleibt bei so etwas mal ernst, ist nicht leicht 🙂

Warum nicht jede CVE Lücke auch ein echtes Problem ist

Jetzt müssen wir erst mal verstehen, wer betroffen ist.

Es geht um den SSH-Agenten. Dessen Job ist das Bereitstellen von Schlüsseln zu Zugängen beim Versuch sich per SSH auf einem Server einzuloggen und läuft auf der CLIENTEN-Seite. Also bei EUCH auf dem PC. Der Gnome-KeyRing-Daemon ist z.b. so ein SSH-AGENT.

Wenn jemand ssh username@servername eingibt, sieht ssh den Agenten, fragt den ob der einen passenden Key dafür kennt und wenn der Key für die Benutzung zu diesem Server freigegeben ist, dann bekommt ssh den Key und kann sich damit anmelden, oder zumindest es probieren. Natürlich kann man einen SSH-Agenten auch auf einem Server laufen lassen, macht z.B. Sinn wenn man einen Server als einzigen Zugang ins Netz betreibt und sich dann von dort „intern“ (oder extern)  weiter verbindet. Auf einem Multidomain-Webserver ist das aber kein normales Szenario, deswegen läuft das auf unserem Server auch nicht, wäre auch egal, wie Ihr gleich lesen könnt.

Mit dem Befehl ssh-add fügt man Schlüssel in den Agenten ein. Dabei kann man bestimmte Restriktionen setzen, z.b. bei welchen Servern der Key nur erlaubt ist. Und genau da setzte die Sicherheitslücke an, die hatten einfach vergessen die Zugriffsmaske im Code zu vereinigen. Nicht mal eine ganze Anweisung war nötig um das zu fixen:

– int r, constrained = (life || confirm);
+ int r, constrained = (life || confirm || dest_constraints);

Als Folge davon sagte zwar derjenige, der den Schlüssel hinzufügte, daß z.B. der Zugriff mit dem Key auf 1.2.3.4 nicht erlaubt ist, er war dann aber doch möglich. Mit der Sicherheit des zuverbindenen Servers, hat das nichts zu tun, wenn der den Key sieht und der Key für den Userzugang ok ist, dann darf der Key bzw. der User auch einloggen.

Das bedeutet, selbst wenn ein angreifbarer Agent auf unserem Webserver läuft, und der per SSH eingeloggte Benutzer diesen Agenten erreichen könnte und den fingierten Key hinzugefügt bekommt, kann er sich auf dem Server keine Rechte erschleichen. Das diese Lücke überhaupt ausgenutzt werden kann, bedarf folgendem:

1. Ein System X zu dem ein Angreifer nicht privilegierten Zugriff hat, das sich per SSH irgendwo einloggt.
2. Das der Angreifer einen präparierten Key an den Admin dieses System übermittelt.
3. Das der Admin den Key auf anderen Servern einrichtet.
4. Das der Admin den Key auf dem System X mit Restriktionen hinzufügt.
5. Das der Angreifer bestimmen kann, wo sich System X hin verbinden soll.

Wenn man jetzt mal ein paar Sekunden über die Punkte 1-3 reflektiert, stellt man fest, daß 4 und 5 gar nicht nötig sind, wenn das „Ziel“ des Angreifers direkt erreichbar wäre. Da könnte er den gerade von Admin hinzugfefügten Key direkt benutzen, schließlich hat er den ja schon.  Es macht also nur Sinn, wenn es sich um Zielsysteme handelt, die nicht öffentlich erreichbar sind (oder man von einer bestimmten IP kommen muß).

Schlußfolgerungen

1. Es funktioniert nur, wenn ein Agent läuft.
2. Es ist nur relevant für Zugriffe auf andere Server, nicht dem, auf dem der Agent läuft. (Außer der Admin war so dämlich, den Key auf dem Server auch direkt freizugeben.)
3. Es macht nur in komplexen Remote Szenarien Sinn.

Punkt 1 ist aber das absolute Killerargument, weil ohne den Agenten, gibt es auch keine Lücke.

Da heute eine neue Version von OpenSSH gebaut wurde, weil ich mit dem Maintainer von OpenSSH  Dmitry Belyavskiy von RedHat seit Wochen in Kontakt stand und den Patch geliefert habe, hat sich das Problem erledigt und  Ihr könnt jetzt mal OpenSSH updaten gehen 😀 Ich habe mit Dmitry abgesprochen, daß das Update nach den Automatischen Tests direkt ins Stable kommt. Es müßte jetzt also schon bereit sein für Euch 😉  Auf unserem Cluster haben wir das, von Euch aus betrachtet, schon gestern aktualisiert. Von hier aus nochmal ein dickes Danke an Dmitry! 😀

Was mich ein bisschen stört ist der CVE Score von 9.8. Der ist eigentlich nicht angebracht, weil das valide Angriffszenario eher selten zum Einsatz kommt, denn niemand hindert den Angreifer daran, seinen Key bei einem Loginversuch direkt anzugeben: ssh -i kompromitierter.key user@servername . Den Umweg über den ssh-agent kann man sich dabei sparen.

Update Freitag:

Das mit dem „Update direkt ins stable schieben“ hat Dmitry leider vergeigt, daher:

dnf –enablerepo=updates-testing update openssh

Dann kommt das Update gleich.