Kees Cook de Google ha llamado a modernizar el proceso de manejo de errores en el núcleo de Linux

Kees Cook, ex-administrador principal de sistemas de kernel.org y líder del equipo de seguridad de Ubuntu, actualmente trabajando en Google para asegurar Android y ChromeOS, expresó su preocupación sobre el actual proceso de corrección de errores en las ramas estables del núcleo. Cada semana se incluyen alrededor de cien correcciones en las ramas estables, y tras el cierre de la ventana de recepción de cambios para la siguiente versión, se acumulan cerca de mil (los mantenedores retienen las correcciones hasta el cierre de la ventana, y después de la formación de "-rc1" publican todo de una vez), lo cual es demasiado y requiere un gran esfuerzo para mantener los productos basados en el núcleo de Linux.

Según Kees, el proceso de manejo de errores en el núcleo no recibe la atención adecuada y le faltan al menos 100 desarrolladores adicionales para coordinarse en esta área. Los principales desarrolladores del núcleo corrigen regularmente los errores, pero no hay garantías de que estas correcciones se trasladen a las versiones del núcleo utilizadas por los fabricantes de terceros. Los usuarios de varios productos basados en el núcleo de Linux tampoco tienen la posibilidad de verificar qué errores han sido corregidos y qué núcleo se utiliza en sus dispositivos. En última instancia, los fabricantes son responsables de la seguridad de sus productos, pero debido a la alta intensidad de las publicaciones de correcciones en las ramas estables del núcleo, se encuentran ante la decisión de llevar todas las correcciones, seleccionar solo las más importantes o ignorar todas las correcciones.

La solución óptima sería transferir solo las correcciones y vulnerabilidades más importantes, pero el principal problema radica en identificar tales errores entre el flujo general. La mayoría de los problemas emergentes son el resultado del uso del lenguaje C, que requiere gran precisión al trabajar con memoria y punteros. La situación se agrava porque muchas correcciones potenciales de vulnerabilidades no se acompañan de identificadores CVE o reciben tal identificación un tiempo después de la publicación del parche. En estas circunstancias, a los fabricantes les resulta muy difícil distinguir las correcciones secundarias de los problemas importantes que afectan la seguridad. Según las estadísticas, más del 40 % de las vulnerabilidades se corrigen antes de recibir CVE, y el retraso promedio entre la emisión del parche y la asignación de CVE es de tres meses (es decir, inicialmente el parche se percibe como un error común, pero solo después de unos meses se hace evidente que se trató de una corrección de vulnerabilidad).

En consecuencia, al no tener una rama separada para las correcciones de vulnerabilidades y no recibir información sobre la relación de seguridad de un determinado problema, los fabricantes de productos basados en el núcleo de Linux tienen que seguir trasladando todas las correcciones de las nuevas ramas estables. Pero este trabajo requiere un gran esfuerzo y enfrenta resistencia en las empresas debido al temor a la aparición de cambios regresivos que puedan afectar el funcionamiento normal del producto.

Recordemos que, según Linus Torvalds, todos los errores son importantes y las vulnerabilidades no deberían separarse de otros tipos de errores ni destacarse en una categoría más prioritaria. Esta opinión se explica porque para un desarrollador común, que no se especializa en cuestiones de seguridad, no es evidente la relación entre una corrección y una vulnerabilidad potencial (para muchas correcciones, solo una auditoría separada permite entender que están relacionadas con la seguridad). Según Linus, la tarea de identificar entre el flujo general de correcciones las vulnerabilidades potenciales debe ser asumida por especialistas en seguridad de los equipos responsables del mantenimiento de los paquetes del núcleo en las distribuciones de Linux.

Kees Cook considera que la única solución para mantener la seguridad del núcleo con costos razonables a largo plazo es la reorientación de ingenieros en las empresas que se dedican a portar correcciones a versiones locales del núcleo, hacia un trabajo conjunto y coordinado en el mantenimiento de correcciones y vulnerabilidades en el núcleo principal (upstream). En la actualidad, muchos fabricantes utilizan versiones no tan recientes del núcleo en sus productos y realizan backporting de correcciones por su cuenta, lo que resulta en que los ingenieros de diferentes empresas duplican el trabajo unos de otros al resolver el mismo problema.

Por ejemplo, si 10 empresas, cada una con un ingeniero dedicado al backporting de las mismas correcciones, reorientaran a esos ingenieros para que corrigieran errores en el upstream, en lugar de portar una sola corrección, podrían arreglar 10 errores distintos en beneficio común o participar en la revisión de los cambios propuestos y evitar que se incluya código con errores en el núcleo. Los recursos también podrían destinarse a desarrollar nuevas herramientas para pruebas y análisis de código que permitan identificar automáticamente, en una fase temprana, clases típicas de errores que surgien una y otra vez.

Kees Cook también sugiere utilizar más activamente las pruebas automatizadas y de fuzzing directamente en el proceso de desarrollo del núcleo, aplicar sistemas de integración continua y abandonar la arcaica gestión del desarrollo a través de correo electrónico. Actualmente, la eficacia de las pruebas se ve obstaculizada porque los procesos principales de prueba están separados del desarrollo y ocurren solo después de la formación de las versiones. Kees también recomendó para reducir el número de errores utilizar durante el desarrollo lenguajes que proporcionen más un alto nivel de seguridad, como Rust.

Fuente: opennet.ru