Denegación de servicio en NetBSD a través de IPsec

NetBSD es un sistema operativo gratuito y de código abierto, catalogado en el grupo de sistemas operativos Unix-like (parecidos a Unix). Está enfocado en la claridad del código, diseño cuidadoso y portabilidad sobre múltiples arquitecturas. Precisamente, su lema principal es ‘Of course it runs NetBSD’, y multitud de fuentes afirman que es el sistema completo que corre en más arquitecturas. Si bien es probable que el kernel Linux corra en más arquitecturas, NetBSD como distribución completa con múltiples utilidades básicas en un sistema operativo ganaría el pulso.

El asunto que nos trae hoy es el descubrimiento de múltiples vulnerabilidades en la implementación de IPsec. Esta implementación forma parte del espacio del kernel, y se encarga de implementar el conjunto de protocolos del mismo nombre, que extienden la funcionalidad del protocolo IP para cifrar y/o autenticar sus paquetes. La forma clásica en la que se presenta es como parte de una red privada virtual, conocido por sus siglas en inglés ‘VPN’.

Concretamente, las vulnerabilidades se encuentran tanto antes como después de cifrar y autenticar, y oficialmente se anuncia que los impactos son denegación de servicio y corrupción de memoria, ambos explotables remotamente. Una de las formas clásicas de denegación de servicio consiste en explotar una vulnerabilidad que corrompe la memoria de un proceso, ocasionando un funcionamiento anómalo que termina accediendo a una zona de memoria no permitida y el proceso se cierra como medida de protección.

Pero si se tiene el poder de corromper la memoria, es posible en algunos escenarios que la corrupción controlada y cuidadosamente diseñada de ésta nos permita ejecutar código que nos interese. A veces incluso especificando explícitamente el código como parte de la entrada anómala que provoca la corrupción (por contraposición a ejecutar otro código ya existente en la memoria del proceso, por redirección del flujo de ejecución). En este caso el boletín no especifica si es posible ejecutar código de forma remota, aunque dada la cantidad de vulnerabilidades (siete) y no afirmar lo contrario, no es posible descartar este impacto. Quizás en las próximas semanas alguien publica un reporte afirmando este impacto tras buscarle las cosquillas al kernel…

Todas las vulnerabilidades afectan a partir de la rama 6, y ya han sido corregidas. Para aplicar las correcciones, es necesario obtener el código fuente del kernel de una versión corregida, compilarlo, instalarlo y reiniciar el sistema. Maxime Villard es el responsable de estos descubrimientos.