Kees Cook, ex administrador jefe de sistemas de kernel.org y líder del equipo de seguridad de Ubuntu, demostró la capacidad de crear una confirmación cuyo identificador abreviado es el mismo que una confirmación agregada previamente al kernel de Linux. El experimento se realizó para confirmar la viabilidad de cambiar a identificadores de confirmación abreviados de 16 caracteres en el kernel de Linux, discutidos previamente en la lista de correo de desarrolladores del kernel, pero no aprobados por Linus Torvalds.
Los identificadores de confirmación acortados se forman dejando los primeros 12 caracteres del hash SHA-1 (48 bits de 160 bits). Dado que la cantidad de objetos en el kernel identificados a través del hash SHA-1 ha superado los 13 millones, es cuestión de tiempo antes de que se produzcan colisiones al utilizar un prefijo de 12 caracteres. Como ejemplo, se muestran objetos ya agregados al kernel, interseccionándose en sus identificadores de 11 caracteres. Además, se menciona que la intersección de identificadores de 12 caracteres ya se registró en octubre, pero fue detectada por la utilidad checkpatch antes de que se enviara el parche.
Los identificadores abreviados se utilizan al publicar enlaces cortos a confirmaciones y también se indican al enviar cambios en la etiqueta "Correcciones", como un enlace a la confirmación en la que se solucionó el problema en el parche enviado (por ejemplo, "Correcciones: e21d2170f366" ). Las colisiones en las que se asocian múltiples cambios diferentes con un único identificador abreviado pueden interrumpir el análisis y las herramientas de verificación de cambios que tienen en cuenta el contenido de las etiquetas de correcciones. Por ejemplo, estas etiquetas se tienen en cuenta en el controlador check_fixes utilizado en la rama linux-next, así como en scripts para analizar correcciones de vulnerabilidades y rastrear el ciclo de vida de los parches.
Linus Torvalds se mostró escéptico sobre la propuesta de aumentar el tamaño mínimo de los identificadores acortados, ya que de hecho el número de confirmaciones en el repositorio es notablemente menor que el de objetos (aproximadamente 1/8). Lo más probable es que, si se producen intersecciones aleatorias, sean entre una confirmación y un objeto de algún otro tipo (por ejemplo, un blob o una rama). En su opinión, los identificadores abreviados se abrevian para que sean visuales, legibles y fáciles de citar, y todavía no existen requisitos previos objetivos para aumentar su tamaño.
Uno de los desarrolladores propuso lograr una reducción de tamaño y al mismo tiempo aumentar el número de bits significativos utilizando un nuevo formato basado en la codificación Base36 (caracteres 0-9a-z) en lugar de dígitos hexadecimales. Según Linus, tal cambio creará más problemas de los que resolverá. Por ejemplo, deberá agregar soporte para el nuevo formato a las utilidades existentes e ingresar un identificador de formato para distinguir entre el formato antiguo y el nuevo.
Para demostrar que el problema con los identificadores acortados no es especulativo y su solución no debe retrasarse, Case Cook creó un cambio en la documentación del kernel, cuyo identificador acortado (1da177e4c3f4) coincidía con el identificador de la confirmación para crear la rama 2.6.12 del kernel. .2-rc6. La colisión se encontró en 3080 horas de cálculos en un sistema con una GPU NVIDIA GeForce RTX XNUMX.
La selección se realizó utilizando el kit de herramientas Lucky-Commit: se agregaron espacios aleatorios al texto del parche de destino hasta que el prefijo SHA-12 de 1 caracteres coincidiera con los prefijos de confirmación que ya existían en el kernel. Según Case, el problema no son tanto las intersecciones aleatorias como la posibilidad de manipular identificadores acortados con fines maliciosos, por ejemplo, para eludir algunos controles.
Fuente: opennet.ru
