Alboroto de seguridad del kernel de Linux: lo que algunas personas se perdieron


Comentario: No es realmente muy interesante que los investigadores de la Universidad de Minnesota hayan introducido errores en el kernel de Linux. Lo que importa es lo que hubiera pasado después.

security-remote-work.jpg

Imagen: iStockphoto / Igor Kutyaev

Recientemente el La comunidad del kernel de Linux estaba en llamas debido a los esfuerzos de los investigadores de la Universidad de Minnesota para Torpedear intencionalmente la seguridad de Linux mediante el envío de parches defectuosos. Mientras que la El Departamento de Ciencias de la Computación de la Universidad se disculpó, el daño ya estaba hecho, y el mantenedor del kernel de Linux Greg Kroah-Hartman prohibió a la Universidad contribuir al kernel.

Independientemente de cómo se sienta acerca de lo que hicieron estos investigadores (Chris Gaun, por ejemplo, argumentó, «Un investigador mostró cómo las vulnerabilidades pueden superar FÁCILMENTE (el) proceso de aprobación»), no se trata realmente de Linux, o seguridad de código abierto. Siempre se ha dado el caso de que es posible introducir un código incorrecto en buenos proyectos de código abierto. El application de código abierto no es intrínsecamente seguro. Más bien, es el código abierto proceso que es seguro, y aunque ese proceso se activa durante el desarrollo, podría decirse que es más potente después de que se descubren las vulnerabilidades.

VER: Los 5 principales lenguajes de programación que deben aprender los administradores de sistemas (PDF gratuito) (TechRepublic)

Dime algo que no sepa

Las organizaciones de todos los tamaños han dependido de Linux para el rendimiento y la seguridad durante décadas de hecho, esas mismas organizaciones dependen de una amplia gama de código abierto, en common. Un nuevo informe de Synopsys sugiere que el la aplicación de software promedio depende de más de 500 componentes de código abierto. Nunca hemos dependido más del código abierto, y tendemos a justificar al menos parte de esa dependencia basándonos en la notion de que el código abierto es seguro.

Esto no significa que el código abierto, en common, o el kernel de Linux, específicamente, sea de alguna manera impermeable a las fallas de seguridad. De echo, La desarrolladora del kernel de Linux, Laura Abbott, ha escrito que las fallas son un procedimiento operativo estándar:

El problema con el enfoque que adoptaron los autores (investigadores de la Universidad de Minnesota) es que en realidad no muestra nada particularmente nuevo. La comunidad del kernel ha sido consciente de esta brecha durante un tiempo. Nadie necesita poner errores intencionalmente en el kernel, somos perfectamente capaces de hacerlo como parte de nuestro flujo de trabajo typical. Yo, personalmente, he introducido errores como los que introdujeron los investigadores, no porque quiera derribar el kernel desde adentro, sino porque no soy infalible.

Hacer que estas fallas particulares se combinen para crear un problema de seguridad significativo, continuó, sería un esfuerzo de varios años, con muchas cosas que podrían salir mal (o, mejor dicho, bien) en el camino:

En realidad, convertir esto en un ataque probablemente implicaría la aceptación de varios parches de coordinación y luego esperar a que aparezcan en las distribuciones. Eso es potencialmente un período de tiempo de varios años dependiendo de la distribución en cuestión. Esto también supone que los errores no se encontrarán y corregirán mientras tanto… (T) no hay garantía de que el código que envíe permanecerá en la forma que desea. Realmente tendrías que estar en él a largo plazo para que un ataque como este funcione. Estoy seguro de que hay actores que podrían lograrlo, pero la mejor solución aquí es aumentar las pruebas y la corrección de errores, algo que Greg (Kroah-Hartman) ha estado solicitando durante mucho tiempo.

BIEN BIEN. Pero supongamos que alguien hizo sácalo. ¿Entonces que? Bueno, ahí es cuando la seguridad de código abierto realmente muestra su valía.

Es un proceso

Ya he escrito sobre esto antes, pero es importante recordar que la seguridad siempre se trata del proceso, no del computer software en sí. Ningún desarrollador, por talentoso que sea, ha escrito software package libre de errores. Los errores, según el punto anterior de Abbott, son una constante porque la imperfección humana es una constante. Sí, podemos intentar probar tantos errores como sea posible, pero los errores permanecerán, ya sea que se hayan depositado intencionalmente en un proyecto o se hayan creado de forma no intencionada. Por lo tanto, la verdadera seguridad entra en acción una vez que se lanza el software, y las personas pueden descubrir las fallas antes de que se conviertan en problemas graves, o se informan y se toman medidas después del lanzamiento.

O, como ha dicho el director ejecutivo y cofundador de Technique Initiative, Adam Jacob postulado, «La pregunta es, ¿qué tan rápido puede reaccionar ante la interrupción en su cadena de suministro?»

Allá por 2007, Mitchell Ashley articulado cómo esto podría funcionar en la práctica:

(En código abierto), los problemas de seguridad suelen ser los primeros en notificarse. Si los problemas de seguridad no se solucionan de inmediato, el proyecto de código abierto será etiquetado como patético por los usuarios, que pasarán a la siguiente opción. Además, la apertura de la divulgación de vulnerabilidades significa que los autores de program están incentivados para solucionar problemas de seguridad rápidamente. Si no responden rápidamente, corren el riesgo de que otros bifurquen el proyecto y se hagan cargo de los autores que no se mantendrán al día con el mercado de usuarios de código abierto.

Más tarde, expresé pensamientos similares, argumentando que «el application de código abierto no es intrínsecamente más (o menos) seguro, sino que ofrece un proceso inherentemente mejor para proteger el código. Los errores en el código de fuente abierta, cuando se descubren, se corrigen rápidamente a través de un código abierto proceso.» Como tal, el hecho de que los investigadores de la Universidad de Minnesota hayan podido inyectar fallas en el kernel de Linux no es la verdadera historia. Tampoco es la historia que la comunidad del kernel atrapó al actor malo antes de que el código se enviara a producción, aunque ese es un beneficio actual de las prácticas de desarrollo de código abierto.

No, la verdadera historia es que incluso si esas fallas permanecieran, si alguna vez se convirtieran en un problema, el proceso para solucionarlas sería rápido. No habría que esperar a que alguna empresa determinara el momento óptimo para informar al mundo sobre los problemas. Más bien, las correcciones estarían disponibles casi de inmediato. Ese es el proceso mediante el cual el código abierto se vuelve y permanece seguro.

Divulgación: trabajo para AWS, pero las opiniones expresadas en este documento son mías.

Ver también





Enlace a la noticia primary