Confiabilidad de kernel.org después del ataque

15

¿Cuáles son las implicaciones de seguridad del compromiso de kernel.org en la confiabilidad de la base de código alojada en el repositorio Git del sitio? El anuncio de hoy explicó las mitigaciones proporcionadas por los hashes de 160 bits, el reflejo del sitio y la naturaleza distribuida del esfuerzo de desarrollo. ¿Esas afirmaciones son sólidas considerando que los hashes para el repositorio principal de Git están colocados junto con el código que ellos tienen y el uso / duplicación típico a la luz del hecho de que el sitio se vio comprometido durante 17 días antes de la detección? Finalmente, ¿qué mejoras, si las hubiera, podrían sugerirse en función de este evento?

    
pregunta zedman9991 01.09.2011 - 22:49
fuente

2 respuestas

20

Bueno, en lo que respecta al uso de Git, resulta que el software y la naturaleza distribuida hacen mucho para proteger el código y detectar modificaciones maliciosas. Para empezar, no se pueden modificar las confirmaciones antiguas a menos que coincidan con el hash SHA-1 correspondiente. Incluso si una confirmación coincidiera con un determinado SHA-1, afectaría a los hashes SHA-1 secundarios, por lo que queda descartado. Nada más antiguo que la fecha de la infracción podría modificarse razonablemente o rompería el repositorio y la sincronización.

Se podrían agregar compromisos en ese período de 17 días. Debido a que las marcas de tiempo son parte del hash SHA-1 para un compromiso, podemos restringir la lista de compromisos "sospechosos" mirando cualquier cosa anterior a la última confirmación antes de la infracción o cualquier cosa en la que la fecha del niño de la confirmación sea menor que la fecha. fecha de los padres Si alguna vez has intentado alterar un commit en git después de que llegue a un repositorio compartido, entiendes lo obvio que es que algo histórico fue alterado.

Debido a que las copias completas del hash del kernel que contienen el historial completo están tan ampliamente distribuidas y siempre se actualizan de manera incremental siguiendo una cadena de confirmaciones que no se pueden revertir sin que el usuario lo sepa, el código fuente del kernel es realmente seguro incluso cuando el sitio web de alojamiento está comprometido.

Finalmente, debido a que solo un número limitado de personas pueden comprometerse legítimamente con el kernel, podemos esperar que puedan observar las actualizaciones de sus secciones que no esperan. Los controles humanos de las aprobaciones (una especie de control técnico, pero no así) juegan un papel importante en saber de dónde proviene el contenido.

En definitiva, comprometer la fuente del kernel de manera no detectada mientras está en Git sería uno de los trucos más impresionantes de la década. Uno tendría un tiempo más fácil para deslizar el código a través de los canales adecuados, que parece inocuo pero es malicioso.

    
respondido por el Jeff Ferland 02.09.2011 - 03:20
fuente
4

¿No debería esta pregunta ser titulada "Confiabilidad de kernel.org PRE-ataque"? Pensándolo bien, supongo que esa pregunta ha sido respondida. :-)

Probablemente pasaría la mayor parte de mi tiempo analítico tratando de decidir qué tan seguro estoy de su determinación de la fecha de ataque más temprana posible.

    
respondido por el Steve Dispensa 02.09.2011 - 17:07
fuente

Lea otras preguntas en las etiquetas