Kees Cook, ex CSO de kernel.org y líder del equipo de seguridad de Ubuntu, que ahora trabaja para Google para proteger Android y ChromeOS, expresó su preocupación por el proceso actual de corrección de errores en las ramas estables del kernel. Cada semana, se incluyen alrededor de cien correcciones en ramas estables, y después de cerrar la ventana para aceptar cambios para la siguiente versión, se acerca a mil (los mantenedores mantienen las correcciones hasta que se cierra la ventana, y después de la formación de "-rc1" publicar los acumulados de una vez), lo cual es demasiado y requiere mucha mano de obra para el mantenimiento de productos basados en el kernel de Linux.
Según Keys, no se presta la debida atención al proceso de trabajar con errores en el kernel y el kernel carece de al menos 100 desarrolladores adicionales para el trabajo coordinado en esta área. Los desarrolladores principales del kernel corrigen errores periódicamente, pero no hay garantía de que estas correcciones se trasladen a variantes del kernel utilizadas por terceros. Los usuarios de varios productos basados en el kernel de Linux tampoco tienen forma de controlar qué errores se corrigen y qué kernel se utiliza en sus dispositivos. Los proveedores son en última instancia responsables de la seguridad de sus productos, pero con una tasa muy alta de parches en las ramas estables del kernel, se enfrentaron a la elección entre respaldar todos los parches, transferir selectivamente los más importantes o ignorar todos los parches.
La solución óptima sería migrar solo las correcciones y vulnerabilidades más importantes, pero el principal problema es aislar dichos errores del flujo general. La mayoría de los problemas que surgen se deben al uso del lenguaje C, que requiere mucho cuidado al tratar con la memoria y los punteros. Para empeorar las cosas, muchas posibles correcciones de vulnerabilidades no cuentan con identificadores CVE o reciben dicho identificador algún tiempo después de la publicación del parche. En tales condiciones, es muy difícil para los fabricantes separar las correcciones menores de los problemas de seguridad importantes. Según las estadísticas, más del 40% de las vulnerabilidades se corrigen antes de que se asigne un CVE, y el retraso medio entre el lanzamiento de un parche y la asignación de un CVE es de tres meses (es decir, al principio, el parche se percibe como un parche común). error, pero sólo después de unos meses queda claro que la vulnerabilidad se ha solucionado).
Como resultado, sin tener una rama separada con correcciones para vulnerabilidades y sin recibir información sobre la conexión de seguridad de un problema en particular, los fabricantes de productos basados en el kernel de Linux deben transferir continuamente todas las correcciones desde ramas estables nuevas. Pero este trabajo requiere mucho trabajo y encuentra resistencias en las empresas por temor a cambios regresivos que puedan alterar el funcionamiento normal del producto.
Recuerde que, según Linus Torvalds, todos los errores son importantes y las vulnerabilidades no deben separarse de otros tipos de errores ni asignarse a una categoría separada de mayor prioridad. Esta opinión se explica por el hecho de que para un desarrollador común que no se especializa en problemas de seguridad, la conexión entre una solución y una vulnerabilidad potencial no es obvia (para muchas soluciones, solo una auditoría separada le permite comprender qué se relacionan con la seguridad). ). Según Linus, depende de los equipos de seguridad de los equipos responsables de mantener los paquetes del kernel en las distribuciones de Linux aislar las vulnerabilidades potenciales del flujo general de parches.
Kees Cook cree que la única solución para mantener el kernel seguro a un costo razonable a largo plazo es que las empresas trasladen a los ingenieros involucrados en la migración de parches a las compilaciones locales del kernel para que trabajen de manera colaborativa y coordinada para mantener los parches y las vulnerabilidades en el kernel ascendente. En su forma actual, muchos fabricantes no utilizan la última versión del kernel en sus productos y corrigen el backport por su cuenta, es decir. Resulta que los ingenieros de diferentes empresas duplican el trabajo de los demás y resuelven el mismo problema.
Por ejemplo, si 10 empresas, cada una con un ingeniero que respalda las mismas correcciones, redirigen a esos ingenieros para que corrijan errores en sentido ascendente, entonces, en lugar de trasladar una solución, podrían corregir 10 errores diferentes para el bien común o unirse a la revisión de los cambios propuestos. evitar que se incluya código con errores en el kernel. También se podrían dedicar recursos a la creación de nuevas herramientas para pruebas y análisis de código, lo que permitiría en una etapa temprana identificar automáticamente clases típicas de errores que aparecen una y otra vez.
Kees Cook también sugiere un uso más activo de pruebas automatizadas y fuzzing directamente en el proceso de desarrollo central, el uso de sistemas de integración continua y el abandono de la gestión de desarrollo arcaica a través del correo electrónico. Actualmente, las pruebas efectivas se ven obstaculizadas por el hecho de que los principales procesos de prueba están separados del desarrollo y ocurren después de la formación de las versiones. Keys también recomendó utilizar lenguajes más seguros, como Rust, para reducir errores.
Fuente: opennet.ru