Êtes-vous concerné par CVE-2019-14899 ? Une liste de vérification pour le noyau

Un scanner signale CVE-2019-14899 sur une machine qui utilise un VPN depuis des années, et le premier réflexe est de déclarer le VPN cassé. C’est le mauvais cadre. Le problème divulgué concerne un attaquant sur le réseau local de la victime qui déduit des informations sur certaines connexions TCP, pas un site web qui déchiffre votre tunnel.

Passez les quatre vérifications ci-dessous dans l’ordre. Chacune soit resserre le problème, soit met fin à l’enquête.

Vérification 1 : l’avis couvre-t-il votre noyau

Consultez la fiche de votre propre distribution, pas le résumé d’un blog sur une date de sortie. La page de sécurité d’Ubuntu pour cette CVE liste le paquet linux générique pour 18.04 LTS comme vulnérable avec le correctif reporté, et suit d’autres paquets de noyau sur des lignes séparées. Faites correspondre votre version en cours et votre paquet de noyau à la bonne ligne. Un numéro de version qui semble familier n’est pas une correspondance.

Un résultat de scanner signifie que l’identifiant s’applique à quelque chose dans votre inventaire. Il ne signifie pas qu’un appareil voisin a exploité la machine.

Vérification 2 : qui est l’attaquant dans le modèle

Le modèle de menace suppose un attaquant adjacent capable d’interagir avec le réseau d’accès de la victime. C’est une position précise, pas un service distant quelconque à qui votre nœud de sortie déplaît. Si les utilisateurs se connectent depuis un café, l’hypothèse est réaliste ; s’ils sont derrière un réseau local d’entreprise géré, c’est une autre conversation.

Laissez ouverte la question de la confiance dans le réseau local même lorsque le tunnel est chiffré. Le chiffrement répond à une autre question que l’adjacence.

Vérification 3 : sur quelle couche vous appuyez-vous

Un HTTPS correctement validé apporte sa propre protection pour les enregistrements applicatifs, et TLS 1.3 authentifie ces données de bout en bout. Il ne promet pas qu’un attaquant ne peut pas interrompre la connexion TCP sous-jacente. Une application peut donc être sûre à lire et pourtant interruptible, et une interruption n’est pas le même résultat qu’une divulgation. Séparez les deux avant d’évaluer le risque.

Cette distinction compte pour le rapport. Elle transforme une affirmation vague selon laquelle le VPN est peu sûr en une déclaration bornée sur ce qu’un attaquant adjacent pourrait observer ou interrompre.

Vérification 4 : quelle atténuation avez-vous réellement déployée

La divulgation traite des atténuations de routage et de filtrage et est explicite sur leurs limites, y compris le filtrage de chemin inverse et les routes asymétriques. Ne collez pas une valeur sysctl sur chaque hôte VPN et ne dites pas que c’est corrigé. Le filtrage de chemin inverse interagit avec le routage, donc une valeur qui aide une topologie peut en casser une autre.

La vérification est une commande, pas une case à cocher. sysctl net.ipv4.conf.all.rp_filter montre la valeur globale, et sysctl net.ipv4.conf.tun0.rp_filter montre la valeur par interface qui s’applique réellement. Lisez les deux avant et après tout changement.

Utilisez les recommandations de la distribution et votre propre conception de routage, puis confirmez le réglage sur l’interface qui porte le tunnel, pas dans un fichier que personne n’a chargé.

Ce qu’il faut noter

Notez l’hypothèse de l’attaquant adjacent, le paquet de noyau en cours, la ligne d’avis que vous avez fait correspondre, l’atténuation déployée et son lieu d’application, ainsi que les protections applicatives en place. Ajoutez la date à laquelle vous avez vérifié l’avis, car ces pages changent. Cette combinaison est une évaluation défendable.

Une date de sortie de système d’exploitation et une connexion VPN qui fonctionne ne sont pas une évaluation. Ce sont deux faits qui se trouvent être faciles à collecter.