Wie man die neue Kernellücke DirtyFrag abwehrt

Moin,

ja, schon wieder eine Lücke im kernel die Rootrechte gibt.. wird grade ein Volkssport so etwas zu finden 🙂

Wie man die neue Kernellücke DirtyFrag abwehrt

Ihr wehrt das ab, indem Ihr diese 4 Kernel-Module blacklistet:

Legt als Root eine Datei an : „/etc/modprobe.d/lockdown-esp.conf

Schreibt das hier rein:

install esp4 /bin/true
install esp6 /bin/true
install rxrpc /bin/true
install afs /bin/true

Eigentlich braucht man nur die ersten drei, aber afs konnte ich noch nie leiden 😉 Scherz beiseite, afs ist ein Modul für das Andrew File System und das pullt rxrpc rein, deswegen einfach mit listen.

dann führt Ihr „rmmod esp4;rmmod esp6;rmmod rxrpc;rmmod afs“ aus und wartet auf Kernel 7.04, der fixt das Problem.

In der zwischenzeit gehen alle VPNs nicht, die IPSEC brauchen, aber Wireguard und diverse andere VPNs (via ssh z.b.) brauchen IPSec nicht und laufen weiter. Seid flexibel 😉

 

„Hello, you reached Interpol, how can we…“ *click*

Heute morgen wurden wir aus Indien mit Fakenews zu unserem Air-Gapped Windows-PC angerufen. 4 mal, beim 5ten mal passierte das hier 😀

„Hello, you reached Interpol, how can we…“ *click*

Irgendwie hat das Wort Interpol bei den Indern eine Allergische Reaktion hervorgerufen, ich konnte nicht mal meinen Fiktiven Namen nennen 🙂

Na gut, da bleibt wohl nur die Forensische Untersuchung. Dazu brauchen wir:

– eine Fritzbox

Denn, eine Fritzbox hat ein Funktion zum Herunterladen von Erweiterten Supportdaten für AVM, das machen wir uns zu nutze 🙂 Und Ihr müßt schnell sein, schon der nächste Anruf kann die Daten die wir brauchen, aus der Liste werfen.

Wie kommt man an die Daten ran?

Dazu loggt Ihr Euch in die Fritz!box ein, notfalls die erweitere Ansicht starten.

1) auf Inhalt klicken

2) auf „Fritz!Box Support“ klicken

3) und Daten speichern

Da sind jetzt jede Menge Daten drin, aber findet man da die richtigen. U.a. ist in den Daten die Anruferliste drin, da taucht die fiktive Nummer auf, die der Anrufer sich gegeben hat. Außerdem stehen die SIP Header der letzten Anrufe zur Verfügung, aber eben nur 3 oder 4, deswegen gleich machen 😉

Wenn Ihr weiter nach der Rufnummer sucht, dann stoßt Ihr zwangsläufig auf das hier:

2022-06-14 10:50:34.284 – IN: my=Fritz.box-IP%16:5060 peer=212.227.124.129 port=5060 UDP, sipiface=none:
INVITE sip:49meinenummer@meine-IP;uniq=4ED0D261308B18E3479371E6DE583 2.0
Via: SIP/2.0/UDP 212.227.124.129;branch=z9hG4bK558a.a1b3af1c4cb4a9d3db770f9c2540be30.0
Via: SIP/2.0/UDP 212.227.67.227;branch=z9hG4bK558a.43f57bddf2d907ac8e703c88816f28c8.0
Via: SIP/2.0/UDP 212.227.124.145;branch=z9hG4bK558a.0196cb5967141d39c551e1029d6b8409.0
Via: SIP/2.0/UDP 212.93.31.246:5060;branch=z9hG4bK1kv0so005gggdkea0210.1
Record-Route: <sip:212.227.124.129;lr=on>
Record-Route: <sip:212.227.67.227;lr=on;ftag=o6at64tt-CC-1067-OFC-1770;did=e18.5d83>
Record-Route: <sip:212.227.124.145;lr=on>
From: „+49458911245“ <sip:+49458911245@Versatel.de;transport=udp;user=phone>;tag=o6at64tt-CC-1067-OFC-1770
To: „+49meinenummer“ <sip:+49meinenummer@1und1.de;user=phone>
Call-ID: y6bosyszeetyiy769vbssneaa9yetzi6@10.18.5.64
CSeq: 1 INVITE
Contact: <sip:+49458911245@212.93.31.246:5060;user=phone;transport=udp>
History-Info: <sip:+49meinenummer@1und1.de>;index=1
History-Info: <sip:+49meinenummer@1und1.de;user=phone>;index=1.1;np=1
Max-Forwards: 59
P-Early-Media: supported
Supported: timer
Min-SE: 90
Session-Expires: 1800;refresher=uac
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, INFO, PRACK, NOTIFY, MESSAGE, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 313

Die IP Adresse im Contact:-Header ist die des Anrufer, oder zumindest die, die er nach außen in dem Netz hatte. Er könnte ja auch per VPN drin sei, oder einen gehackten PC kontrollieren. Diese IP ist das einzige wahre an dem ganzen Anruf, denn um die Verbindung zu halten, müssen die SIP Pakete routebar sein, also kann man keine gefälschten IPs wie bei einem DDOS benutzen.

Mit den Daten oben könnt Ihr dann tatsächlich zur Polizei gehen und Anzeige erstatten, weil es hier tatsächlich einen Ermittlungsansatz gibt. Natürlich sind die Inder nicht wirklich in Deutschland, aber beim Provider der das SIP Gespräch an Euch durchgereicht habt, muß es auch Log zur echten IP geben, weil, wie gesagt, mit gefälschten Ips gehts nicht. Also ist da entweder ein gehackter PC / Telefonanlage im Spiel, oder ein VPN. Auf beides muß man mit IPs zugreifen. So oder so, tut ihr was Gutes 😉

Um die Anrufer aus dem obigen Beispiel kümmert sich die Kripo Wuppertal 😉

Follow-UP: „Hello, you reached Interpol, how can we …“ *click*

Exim: CVE-2019-15846 Root-Exploit und die Abwehr

So, es ist wieder soweit, wir stopfen den Exim gegen CVE-2019-15846. Diese Lücke beinhaltet einen eher ungewöhnlichen Angriffsvektor, jedenfalls für mich. Aus der Richtung hätte ich nicht mit Problemen gerechnet.

CVE-2019-15846: Root-Exploit durch SNI

Was ist das Problem werdet Ihr fragen? Schon mal was von TLS gehört? Nein? Nagut 😉 Das ist der Nachfolger von SSLv3 und wurde 1998 ins Leben gerufen um primär ein Problem zu lösen: Für SSLv3 braucht jede Domain, die das benutzen wollte, eine eigene IP auf dem Server, weil es nicht möglich war, das Cert passend zur aufgerufenen Domain auszuwählen.

Dies wurde durch SNI in TLS 1.0 behoben, so daß Webserver jetzt alle verschlüsselt erreichbaren Domains auf einer einzigen IP hosten konnten. Dazu gibt der Client, dem Web/ oder Mailserver mit, für welche Domain er eine Verbindung aufbauen möchte, bevor die Verbindung wirklich aufgebaut wird.

Genau da liegt das Problem

Der per SNI übergebene Domainname landet beim Exim derzeit ungeprüft im Filesystem und wenn etwas ungeprüft im Filesystem landet, kann man damit einiges anstellen, in diesem Fall Root werden. Das ist eine stark vereinfachte Darstellung, weil ich will ja nicht, daß Ihr Euch daraus einen eigenen Exploit baut 😉

Die Gegenmaßnahme

Mal von den bereits verfügbaren Update-Patchen abgesehen, kann man den Angriff dadurch erschweren, daß man die zum Angriff nötigen Zeichen im SNI blockiert.

Das geht so :

acl_check_mail:

deny condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni}}}}
       message = no invalid SNI for you

deny condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_peerdn}}}}
       message = no invalid tls strings for you

Es wird aber empfohlen das Update einzuspielen, weil nicht ausgeschlossen werden kann, daß dies nicht ausreicht um die Lücke dauerhaft zu schließen.

Für den derzeit bekannten Angriffsvektor gibt es bereits einen Proof-of-Concept Exploit, daher solltet Ihr sehr schnell handeln und noch schneller Updaten!

Fedora patzt beim Update

Das ist dem schnell Updaten wird für Redhat und Fedora Benutzer ein Problem werden, denn es gibt noch keine Updates. Fedora/Redhat hat es komplett verpennt, obwohl ich dem Maintainer höchstselbst eine Headsup Notitz gemailt habe und auf einer von den Distros überwachten Liste, eine entsprechende Nachricht eingegangen ist. Da haben ich und Golem das ja auch her gehabt. Heise Sec meinte, es würde reichen, wenn man das CERT bei Twitter abboniert hat.. ne sorry, reicht nicht 😀

Dann fixt jetzt mal eure Server, mein Cluster ist damit schon durch.

1. Update: 14:48

Wie aus sicherer Quelle bekannt wurde, hat Redhat eine „Urlaubsvertretung“ mit dem Problem betraut, da der Maintainer nicht zur Verfügung steht derzeit, er ist im Urlaub. Ob das die Ursache ist, daß es noch keine Updates gibt, weiß man nicht sicher, aber im Bereich des möglich wärs ja 😉 Sorry Fedora, aber ein bisschen Spot muß sein, ich sehe nämlich immer noch keine Pakete im Buildsystem bauen …

2. Update: 17:11

Das Update von Exim hat jetzt bei Fedora den Status „dringend“/“urgent“ .

3. Update: 18:20

TestRPMs sind verfügbar:

https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-4.92.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-mysql-4.92.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-clamav-4.92.2-1.fc29.x86_64.rpm

4. Update: 19:01

Die RPMs wurden ins Stable gepusht. Damit gehen die Updates jetzt für alle live.

Danke an alle Helfer, Urlauber, Urlaubsunterbrecher und Vertretungen, die es heute Nachmittag dann doch noch geschafft haben und besonders an Heiko Schlittermann, mit dem ich noch die Eckpunkte des Workarounds diskutieren konnte, bevor es offiziell wurde.