¿Le afecta CVE-2019-14899? Una lista de comprobación para el kernel

Un escáner marca CVE-2019-14899 en una máquina que lleva años usando una VPN, y el primer impulso es declarar la VPN rota. Es un marco equivocado. El problema divulgado se refiere a un atacante en la red local de la víctima que infiere información sobre ciertas conexiones TCP, no a un sitio web que descifra su túnel.

Recorra las cuatro comprobaciones siguientes en orden. Cada una o bien acota el problema o bien termina la investigación.

Comprobación 1: el aviso cubre su kernel

Consulte el registro de su propia distribución, no el resumen de la fecha de publicación de un blog. La página de seguridad de Ubuntu para esta CVE enumera el paquete linux genérico para 18.04 LTS como vulnerable con la corrección aplazada y sigue otros paquetes del kernel en filas separadas. Empareje su versión en ejecución y su paquete del kernel con la fila correcta. Un número de versión que parece familiar no es una coincidencia.

Un hallazgo del escáner significa que el identificador se aplica a algo de su inventario. No significa que un dispositivo vecino haya explotado la máquina.

Comprobación 2: quién es el atacante en el modelo

El modelo de amenaza supone un atacante adyacente que puede interactuar con la red de acceso de la víctima. Es una posición concreta, no un servicio remoto cualquiera al que no le gusta su nodo de salida. Si los usuarios se conectan desde una cafetería, la suposición es realista; si están detrás de una LAN corporativa gestionada, es otra conversación.

Mantenga abierta la cuestión de la confianza en la red local incluso cuando el túnel está cifrado. El cifrado responde a una pregunta distinta de la adyacencia.

Comprobación 3: en qué capa confía

Un HTTPS validado correctamente aporta su propia protección para los registros de aplicación, y TLS 1.3 autentica esos datos de extremo a extremo. No promete que un atacante no pueda interrumpir la conexión TCP subyacente. Por tanto, una aplicación puede ser segura de leer y aun así interrumpible, y la interrupción no es el mismo resultado que la revelación. Separe ambas cosas antes de valorar el riesgo.

Esa distinción importa para el informe. Convierte una afirmación vaga de que la VPN es insegura en una declaración acotada sobre lo que un atacante adyacente podría observar o interrumpir.

Comprobación 4: qué mitigación desplegó realmente

La divulgación trata mitigaciones de enrutamiento y filtrado y es explícita sobre sus límites, incluido el filtrado de ruta inversa y las rutas asimétricas. No pegue un valor sysctl en cada host VPN y diga que está resuelto. El filtrado de ruta inversa interactúa con el enrutamiento, así que un valor que ayuda a una topología puede romper otra.

La verificación es un comando, no una casilla. sysctl net.ipv4.conf.all.rp_filter muestra el valor global, y sysctl net.ipv4.conf.tun0.rp_filter muestra el valor por interfaz que realmente se aplica. Lea ambos antes y después de cualquier cambio.

Use las indicaciones de la distribución y su propio diseño de enrutamiento, y luego confirme el ajuste en la interfaz que transporta el túnel, no en un archivo que nadie cargó.

Qué anotar

Anote la suposición del atacante adyacente, el paquete del kernel en ejecución, la fila del aviso con la que coincidió, la mitigación desplegada y dónde se aplica, y las protecciones de aplicación existentes. Añada la fecha en que revisó el aviso, porque esas páginas cambian. Esa combinación es una evaluación defendible.

Una fecha de publicación del sistema operativo y una conexión VPN que funciona no son una evaluación. Son dos hechos que casualmente son fáciles de recopilar.