Sei interessato da CVE-2019-14899? Una lista di controllo per il kernel

Uno scanner segnala CVE-2019-14899 su una macchina che usa una VPN da anni, e il primo istinto è dichiarare la VPN rotta. È la cornice sbagliata. Il problema divulgato riguarda un attaccante sulla rete locale della vittima che deduce informazioni su certe connessioni TCP, non un sito web che decifra il tuo tunnel.

Percorri i quattro controlli qui sotto in ordine. Ognuno o restringe il problema o chiude l’indagine.

Controllo 1: l’avviso copre il tuo kernel

Cerca la scheda della tua distribuzione, non il riassunto di un blog su una data di rilascio. La pagina di sicurezza di Ubuntu per questa CVE elenca il pacchetto linux generico per 18.04 LTS come vulnerabile con la correzione rinviata, e segue altri pacchetti del kernel su righe separate. Abbina la versione in esecuzione e il pacchetto del kernel alla riga giusta. Un numero di versione che sembra familiare non è una corrispondenza.

Un riscontro dello scanner significa che l’identificatore si applica a qualcosa nel tuo inventario. Non significa che un dispositivo vicino abbia sfruttato la macchina.

Controllo 2: chi è l’attaccante nel modello

Il modello di minaccia presuppone un attaccante adiacente che può interagire con la rete di accesso della vittima. È una posizione precisa, non un servizio remoto qualsiasi a cui non piace il tuo nodo di uscita. Se gli utenti si collegano da un bar, l’ipotesi è realistica; se stanno dietro una LAN aziendale gestita, è un’altra conversazione.

Lascia aperta la questione della fiducia nella rete locale anche quando il tunnel è cifrato. La cifratura risponde a una domanda diversa dall’adiacenza.

Controllo 3: su quale livello ti appoggi

Un HTTPS validato correttamente fornisce la propria protezione per i record applicativi, e TLS 1.3 autentica quei dati da estremo a estremo. Non promette che un attaccante non possa interrompere la connessione TCP sottostante. Un’applicazione può quindi essere sicura da leggere e comunque interrompibile, e un’interruzione non è lo stesso esito di una divulgazione. Separa le due cose prima di valutare il rischio.

Questa distinzione conta per il rapporto. Trasforma un’affermazione vaga che la VPN sia insicura in una dichiarazione circoscritta su ciò che un attaccante adiacente potrebbe osservare o interrompere.

Controllo 4: quale mitigazione hai davvero distribuito

La divulgazione discute mitigazioni di instradamento e filtraggio ed è esplicita sui loro limiti, incluso il filtraggio del percorso inverso e le rotte asimmetriche. Non incollare un valore sysctl su ogni host VPN e dire che è risolto. Il filtraggio del percorso inverso interagisce con l’instradamento, quindi un valore che aiuta una topologia può romperne un’altra.

La verifica è un comando, non una casella. sysctl net.ipv4.conf.all.rp_filter mostra il valore globale, e sysctl net.ipv4.conf.tun0.rp_filter mostra il valore per interfaccia che si applica davvero. Leggi entrambi prima e dopo ogni modifica.

Usa le indicazioni della distribuzione e il tuo disegno di instradamento, poi conferma l’impostazione sull’interfaccia che porta il tunnel, non in un file che nessuno ha caricato.

Cosa annotare

Annota l’ipotesi dell’attaccante adiacente, il pacchetto del kernel in esecuzione, la riga dell’avviso abbinata, la mitigazione distribuita e dove è applicata, e le protezioni applicative presenti. Aggiungi la data in cui hai controllato l’avviso, perché quelle pagine cambiano. Questa combinazione è una valutazione difendibile.

Una data di rilascio del sistema operativo e una connessione VPN funzionante non sono una valutazione. Sono due fatti che per caso sono facili da raccogliere.