{"id":122969,"date":"2025-03-25T10:22:42","date_gmt":"2025-03-25T08:22:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz"},"modified":"2025-03-25T10:22:42","modified_gmt":"2025-03-25T08:22:42","slug":"v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","title":{"rendered":"En NixOS se ha propuesto un m\u00e9todo de protecci\u00f3n contra la inserci\u00f3n de backdoors, como en XZ.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Para incluirse en el repositorio de paquetes nixpkgs, utilizado en la distribuci\u00f3n NixOS, se ha propuesto un modo de compilaciones reproducibles que permite detectar casos de inyecci\u00f3n de backdoors en el c\u00f3digo, similar al incidente con el proyecto XZ. El m\u00e9todo de protecci\u00f3n presentado permite descubrir modificaciones en los archivos del c\u00f3digo fuente del lanzamiento que no est\u00e1n presentes en los repositorios de c\u00f3digo. <\/p>\n
La esencia del m\u00e9todo es que el c\u00f3digo fuente de una nueva versi\u00f3n de la aplicaci\u00f3n se compila dos veces: la primera a partir del c\u00f3digo descargado del repositorio git y la segunda a partir del c\u00f3digo distribuido en archivos comprimidos preparados. Si los archivos binarios resultantes de las compilaciones difieren, surge la sospecha de que puede haber modificaciones ocultas en el repositorio o en el archivo comprimido con el c\u00f3digo. <\/p>\n
Recordemos que, en el caso del proyecto XZ, el repositorio de c\u00f3digo no conten\u00eda 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\u00f3 a nivel del sistema de ensamblaje, y el propio c\u00f3digo fuente de XZ coincid\u00eda con el c\u00f3digo del repositorio. Los macros m4 que activaban el backdoor para la herramienta Automake solo estaban incluidos en el archivo preparado con el c\u00f3digo y no estaban presentes en el repositorio. <\/p>\n
El backdoor en XZ fue inyectado por un atacante que logr\u00f3 obtener el estatus de mantenedor en el proyecto. La inyecci\u00f3n del backdoor pas\u00f3 desapercibida desde el principio porque las distribuciones principalmente generan paquetes al cargar el c\u00f3digo de archivos preparados, ya que al cargar el c\u00f3digo para la compilaci\u00f3n se puede utilizar un solo hash para la verificaci\u00f3n de la integridad del archivo del archivo y emplear espejos. La atenci\u00f3n principal durante la verificaci\u00f3n del c\u00f3digo se centra en el an\u00e1lisis del contenido del repositorio, por lo que los diferenciales no evidentes en los archivos no siempre pueden ser detectados de inmediato. <\/p>\n
Para facilitar la verificaci\u00f3n de la correspondencia entre los archivos comprimidos y las instant\u00e1neas del repositorio asociadas a las versiones, algunos proyectos abiertos, como PostgreSQL, han implementado un sistema de generaci\u00f3n repetible de archivos comprimidos. En este caso, se proporciona un conjunto de herramientas que permite crear su propio archivo comprimido a partir del c\u00f3digo, que corresponde completamente al archivo comprimido disponible para su descarga. Si el archivo comprimido creado de forma independiente y el archivo comprimido proporcionado por el proyecto principal difieren, se considera que hay una compromisi\u00f3n del repositorio o del archivo de referencia. <\/p>\n
El problema es que este m\u00e9todo solo se aplica en ciertos casos, mientras que muchos proyectos contin\u00faan incluyendo en los archivos comprimidos artefactos adicionales ausentes en el repositorio principal, tales como p\u00e1ginas man, documentaci\u00f3n, ejemplos, scripts de creaci\u00f3n de paquetes para distribuciones y archivos de compilaci\u00f3n adicionales. Esto suele suceder por razones hist\u00f3ricas y particularidades en los procesos de creaci\u00f3n de versiones. Una simple verificaci\u00f3n de la correspondencia entre el contenido del repositorio y el archivo comprimido no es suficiente en este caso. <\/p>\n
Como soluci\u00f3n, se propone compilar los archivos binarios de la versi\u00f3n tanto del repositorio (por ejemplo, se puede usar el archivo comprimido generado autom\u00e1ticamente en GitHub para la etiqueta de versi\u00f3n) como del archivo preparado por el mantenedor, comparando luego el resultado. Como experimento, esta verificaci\u00f3n se ha propuesto hasta ahora solo para el paquete \u00abxz\u00bb. Si el experimento resulta exitoso, se planea utilizar la verificaci\u00f3n tambi\u00e9n en otros paquetes en nixpkgs. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"