Para incluirse en el repositorio de paquetes nixpkgs, utilizado en la distribución NixOS, se ha propuesto un modo de compilaciones reproducibles que permite detectar casos de inyección de backdoors en el código, similar al incidente con el proyecto XZ. El método de protección presentado permite descubrir modificaciones en los archivos del código fuente del lanzamiento que no están presentes en los repositorios de código.
La esencia del método radica en que el código fuente de la nueva versión de la aplicación se compila dos veces: la primera a partir del código descargado del repositorio git, y la segunda a partir del código distribuido en archivos preparados. Si los archivos binarios resultantes de las compilaciones difieren, surge un motivo de sospecha sobre la existencia de modificaciones ocultas en el repositorio o en el archivo de código.
Recordemos que, en el caso del proyecto XZ, el repositorio de código no contenía cambios sospechosos. Los componentes maliciosos que formaban el backdoor se entregaban dentro de los archivos utilizados en el conjunto de pruebas para verificar el funcionamiento correcto del descompresor XZ. El backdoor se activó a nivel del sistema de ensamblaje, y el propio código fuente de XZ coincidía con el código del repositorio. Los macros m4 que activaban el backdoor para la herramienta Automake solo estaban incluidos en el archivo preparado con el código y no estaban presentes en el repositorio.
El backdoor en XZ fue inyectado por un atacante que logró obtener el estatus de mantenedor en el proyecto. La inyección del backdoor pasó desapercibida desde el principio porque las distribuciones principalmente generan paquetes al cargar el código de archivos preparados, ya que al cargar el código para la compilación se puede utilizar un solo hash para la verificación de la integridad del archivo del archivo y emplear espejos. La atención principal durante la verificación del código se centra en el análisis del contenido del repositorio, por lo que los diferenciales no evidentes en los archivos no siempre pueden ser detectados de inmediato.
Para facilitar la verificación de la correspondencia entre los archivos comprimidos y las instantáneas del repositorio asociadas a las versiones, algunos proyectos de código abierto, como PostgreSQL, han implementado un sistema de generación repetible de archivos comprimidos. En este caso, se proporciona una herramienta que permite crear de manera independiente un archivo comprimido a partir del código, completamente correspondiente al archivo listo disponible para descarga. Si el archivo comprimido creado independientemente y el archivo proporcionado por el proyecto principal difieren, esto indica una posible compromisión del repositorio o del archivo de referencia.
El problema es que este método solo se aplica en ciertos casos, mientras que muchos proyectos continúan incluyendo en los archivos comprimidos artefactos adicionales ausentes en el repositorio principal, tales como páginas man, documentación, ejemplos, scripts de creación de paquetes para distribuciones y archivos de compilación adicionales. Esto suele suceder por razones históricas y particularidades en los procesos de creación de versiones. Una simple verificación de la correspondencia entre el contenido del repositorio y el archivo comprimido no es suficiente en este caso.
Como solución, se ha propuesto compilar los archivos binarios de la versión tanto del repositorio (por ejemplo, se puede usar el archivo generado automáticamente en GitHub para la etiqueta de la versión) como del archivo preparado por el mantenedor, comparando luego los resultados. Por ahora, la inclusión de este tipo de verificación se ha propuesto solo para el paquete «xz». Si el experimento resulta exitoso, se planea utilizar la verificación en otros paquetes dentro de nixpkgs.
Fuente: opennet.ru
