¿Cuánto tiempo permanecen los bugs en el kernel Linux?

Kees Cook, investigador en seguridad y tecnología de Google que tiene entre sus intereses el Kernel Self Protection Project de Linux, decidió iniciar una investigación sobre los bugs históricos de Linux. Para ello, observó 557 documentos sobre bugs con su correspondiente número de CVE, que fueron desde CVE-2008-7316 hasta CVE-2016-2782 (para los que anden perdidos, lo resumiremos diciendo los bugs van desde 2008 hasta 2016).

Debido a que el árbol del código fuente de Linux y el historial de sus muchos cambios son un asunto público, Cook fue capaz de localizar los cambios en el código correspondientes a las correcciones de los bugs con etiqueta CVE, rastreándolos de nuevo para hallar el código fuente correspondiente a los cambios que fueron introducidos en primer lugar. En otras palabras, ha podido obtener una vista objetiva sobre por cuánto tiempo han estado presentes los bugs en el Kernel Linux.

Cook ha catalogado los bugs en diferentes categorías, mostrando también por cuánto tiempo han estado presentes en el kernel Linux. Para ello ha empleado distintos colores según la gravedad.

Cook solo descubrió dos bugs críticos en su investigación: CVE-2014-0038 y CVE-2014-0196 (también conocidos como "on_TTY" o "got root" bug). El primero estuvo presente el kernel durante cinco años, mientras que el segundo estuvo alrededor de dos años. También se puede ver la reciente Dirty Cow, que estuvo 9 años en el Kernel.

De los 34 bugs que fueron etiquetados como de riesgo alto, su exposición de tiempo medio fue de seis años, con algunos que han estado presentes incluso por más de una década. Más del 90% de los bugs (31 de 34) de riesgo alto estuvieron presentes para ser explotados al menos un año. El sumario es:

• Critical: 2 @ 3.3 years
• High: 34 @ 6.4 years
• Medium: 334 @ 5.2 years
• Low: 186 @ 5.0 years

Ante estos descubrimientos, Cook comenta que la corrección de bugs ha tenido como consecuencia la incorporación de otros. Por otro lado también pone de relieve que muchos dispositivos fueron construidos con una versión específica del kernel y muchas veces estos no reciben todos los parches de seguridad necesarios, aumentando así el tiempo de vida de los bugs presentes.

Esa esa la razón por la cual este investigador ha empleado tiempo y esfuerzo en proyectos de autoprotección, así como la caza y purga de bugs. Según él, se necesita mejorar la seguridad colectiva, incluso en un mundo donde hay tantos parches no aplicados. Esto es una llamada a todos los fabricantes para que se pongan las pilas en torno a la seguridad de las versiones del kernel Linux que emplean. Aquí se muestra la diferencia que hay entre un parche disponible, lo cual es bueno en teoría, y un parche implementado, que es bueno en la práctica.

Cook argumenta que los ladrones están pendientes del nuevo código añadido a Linux debido a que este tiene muchas opciones de albergar nuevos bugs que pueden ser explotados.

Fuente: Muy Seguridad | Naked Security