Sind Sie von CVE-2019-14899 betroffen? Eine Kernel-Checkliste

Ein Scanner meldet CVE-2019-14899 auf einer Maschine, die seit Jahren ein VPN nutzt, und der erste Reflex ist, das VPN für defekt zu erklären. Das ist der falsche Rahmen. Der offengelegte Punkt betrifft einen Angreifer im lokalen Netz des Opfers, der Informationen über bestimmte TCP-Verbindungen ableitet, nicht eine Website, die Ihren Tunnel entschlüsselt.

Arbeiten Sie die vier Prüfungen unten der Reihe nach ab. Jede grenzt das Problem ein oder beendet die Untersuchung.

Prüfung 1: deckt der Hinweis Ihren Kernel ab

Suchen Sie den eigenen Eintrag Ihrer Distribution, nicht die Zusammenfassung eines Blogs zu einem Veröffentlichungsdatum. Die Ubuntu-Sicherheitsseite zu dieser CVE führt das generische linux-Paket für 18.04 LTS als anfällig mit aufgeschobener Korrektur und verfolgt andere Kernel-Pakete in getrennten Zeilen. Ordnen Sie Ihre laufende Version und Ihr Kernel-Paket der richtigen Zeile zu. Eine vertraut wirkende Versionsnummer ist keine Übereinstimmung.

Ein Scanner-Treffer bedeutet, dass die Kennung auf etwas in Ihrem Bestand zutrifft. Er bedeutet nicht, dass ein Nachbargerät die Maschine ausgenutzt hat.

Prüfung 2: wer ist der Angreifer im Modell

Das Bedrohungsmodell setzt einen angrenzenden Angreifer voraus, der mit dem Zugangsnetz des Opfers interagieren kann. Das ist eine bestimmte Position, kein beliebiger entfernter Dienst, dem Ihr Ausgangsknoten nicht gefällt. Wenn Nutzer aus einem Café verbinden, ist die Annahme realistisch; sitzen sie hinter einem verwalteten Firmen-LAN, ist es ein anderes Gespräch.

Halten Sie die Frage nach dem Vertrauen ins lokale Netz offen, auch wenn der Tunnel verschlüsselt ist. Verschlüsselung beantwortet eine andere Frage als Nachbarschaft.

Prüfung 3: auf welche Schicht verlassen Sie sich

Korrekt validiertes HTTPS bietet eigenen Schutz für Anwendungsdatensätze, und TLS 1.3 authentifiziert diese Daten Ende zu Ende. Es verspricht nicht, dass ein Angreifer die zugrunde liegende TCP-Verbindung nicht unterbrechen kann. Eine Anwendung kann also sicher zu lesen und dennoch unterbrechbar sein, und eine Unterbrechung ist nicht dasselbe Ergebnis wie eine Offenlegung. Trennen Sie beides, bevor Sie das Risiko bewerten.

Diese Unterscheidung ist für den Bericht wichtig. Sie verwandelt die vage Behauptung, das VPN sei unsicher, in eine begrenzte Aussage darüber, was ein angrenzender Angreifer beobachten oder unterbrechen könnte.

Prüfung 4: welche Gegenmaßnahme haben Sie tatsächlich umgesetzt

Die Offenlegung erörtert Routing- und Filtermaßnahmen und ist ausdrücklich über deren Grenzen, einschließlich Reverse-Path-Filtering und asymmetrischer Routen. Kleben Sie nicht einen sysctl-Wert auf jeden VPN-Host und nennen Sie es behoben. Reverse-Path-Filtering wirkt mit dem Routing zusammen, sodass ein Wert, der einer Topologie hilft, eine andere brechen kann.

Überprüfung ist ein Befehl, kein Häkchen. sysctl net.ipv4.conf.all.rp_filter zeigt den globalen Wert, und sysctl net.ipv4.conf.tun0.rp_filter zeigt den schnittstellenbezogenen Wert, der tatsächlich gilt. Lesen Sie beide vor und nach jeder Änderung.

Nutzen Sie die Vorgaben der Distribution und Ihr eigenes Routing-Design und bestätigen Sie dann die Einstellung auf der Schnittstelle, die den Tunnel trägt, nicht in einer Datei, die niemand geladen hat.

Was festzuhalten ist

Notieren Sie die Annahme des angrenzenden Angreifers, das laufende Kernel-Paket, die zugeordnete Hinweiszeile, die umgesetzte Maßnahme und wo sie greift sowie die vorhandenen Anwendungsschutzmaßnahmen. Fügen Sie das Datum hinzu, an dem Sie den Hinweis geprüft haben, denn diese Seiten ändern sich. Diese Kombination ist eine belastbare Bewertung.

Ein OS-Veröffentlichungsdatum und eine funktionierende VPN-Verbindung sind keine Bewertung. Es sind zwei Fakten, die zufällig leicht zu sammeln sind.