Kees Cook realizo una publicación de blog en la cual ha expresado su preocupación por el proceso de corrección de errores en curso en las ramas estables del kernel de Linux y es que menciona que semana a semana se incluyen alrededor de cien correcciones en las ramas estables,  lo cual es demasiado y requiere mucho esfuerzo para mantener productos basados ​​en el kernel de Linux.

Según Kees, el proceso de manejo de errores del kernel se pasa por alto y el kernel carece de al menos 100 desarrolladores adicionales para trabajar de manera coordinada en esta área. Además de que menciona que los principales desarrolladores del kernel corrigen errores con regularidad, pero no hay garantía de que estas correcciones se transfieran a variantes del kernel de terceros.

Con ello, menciona que 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. En última instancia, los proveedores son responsables de la seguridad de sus productos, pero ante una tasa muy alta de parches en las ramas estables del kernel, se enfrentaron a la opción de migrar todos los parches, migrar selectivamente los más importantes o ignorar todos los parches.

Los desarrolladores de kernel ascendentes pueden corregir errores, pero no tienen control sobre lo que un proveedor descendente elige incorporar a sus productos. Los usuarios finales pueden elegir sus productos, pero generalmente no tienen control sobre qué errores se corrigen ni qué kernel se usa (un problema en sí mismo). En última instancia, los proveedores son responsables de mantener seguros los núcleos de sus productos.

Kees Cook sugiere que la solución óptima sería transferir solo las correcciones y vulnerabilidades más importantes, pero el problema principal es separar dichos errores del flujo general, ya que la mayor cantidad de problemas emergentes es consecuencia del uso del lenguaje C, que requiere mucho cuidado al trabajar con la memoria y los punteros.

Para empeorar las cosas, muchas posibles correcciones de vulnerabilidades no están etiquetadas con identificadores CVE o no reciben un identificador CVE algún tiempo después de que se publique el parche.

En un entorno así, es muy difícil para los fabricantes separar las correcciones menores de los problemas importantes de seguridad. Según las estadísticas, más del 40% de las vulnerabilidades se eliminan antes de la asignación de CVE y, en promedio, el retraso entre la publicación de una solución y la asignación de una CVE es de tres meses (es decir, al principio, se percibe una solución como un error común,

Como resultado, al no tener una rama separada con correcciones para las vulnerabilidades y al no recibir información sobre la conexión con la seguridad de este o aquel problema, los fabricantes de productos basados ​​en el kernel de Linux tienen que transferir continuamente todas las correcciones de las nuevas ramas estables. Pero este trabajo es intensivo en mano de obra y enfrenta resistencia en las empresas debido a los temores de cambios regresivos que podrían interrumpir el funcionamiento normal del producto.

Keys Cook cree que la única solución para mantener el kernel seguro a un costo razonable a largo plazo es trasladar a los ingenieros de parches a las compilaciones del kernel local para que trabajen juntos de manera coordinada para mantener los parches y las vulnerabilidades en el kernel ascendente. Tal como está, muchos proveedores no usan las últimas versiones del kernel en sus productos y arreglos de backport por su cuenta, es decir, resulta que los ingenieros de diferentes empresas duplican el trabajo de los demás, resolviendo el mismo problema.

Por ejemplo, si 10 empresas, cada una con un ingeniero que respalda las mismas correcciones, reorientan a estos ingenieros para corregir errores en sentido ascendente, en lugar de migrar una corrección, podrían corregir 10 errores diferentes para el beneficio general o unirse para revisar los cambios propuestos. Y evitar incluir código con errores en el kernel. Los recursos también podrían usarse para crear nuevas herramientas de análisis de código y pruebas que detectarían automáticamente en una etapa temprana las clases de error típicas que surgen una y otra vez.

Keys Cook también propone utilizar de forma más activa las pruebas automatizadas y fuzzing directamente en el proceso de desarrollo del kernel, utilizar sistemas de integración continua y abandonar la arcaica gestión del desarrollo a través del correo electrónico.

Fuente: https://security.googleblog.com