{"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\/pt\/blog\/news\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","title":{"rendered":"NixOS apresenta m\u00e9todo de prote\u00e7\u00e3o contra inje\u00e7\u00f5es de backdoors, como no XZ","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Para inclus\u00e3o no reposit\u00f3rio de pacotes nixpkgs, utilizado na distribui\u00e7\u00e3o NixOS, foi proposto um modo de compila\u00e7\u00e3o repet\u00edvel, que permite identificar casos de inje\u00e7\u00e3o de backdoors no c\u00f3digo, semelhante ao incidente com o projeto XZ. O m\u00e9todo de prote\u00e7\u00e3o apresentado permite detectar modifica\u00e7\u00f5es nos arquivos de c\u00f3digo-fonte de lan\u00e7amentos que n\u00e3o est\u00e3o presentes nos reposit\u00f3rios de c\u00f3digo. <\/p>\n
A ess\u00eancia do m\u00e9todo \u00e9 que o c\u00f3digo-fonte da nova vers\u00e3o do aplicativo \u00e9 compilado duas vezes \u2014 a primeira a partir do c\u00f3digo carregado do reposit\u00f3rio git e a segunda a partir do c\u00f3digo distribu\u00eddo em arquivos preparados. Se os arquivos bin\u00e1rios resultantes das compila\u00e7\u00f5es diferirem, surge uma suspeita de modifica\u00e7\u00f5es ocultas no reposit\u00f3rio ou no arquivo de c\u00f3digo. <\/p>\n
Lembramos que, no caso do projeto XZ, o reposit\u00f3rio de c\u00f3digo n\u00e3o continha altera\u00e7\u00f5es suspeitas. Os componentes maliciosos que formavam o backdoor eram fornecidos dentro de arquivos usados no conjunto de testes para verificar a corre\u00e7\u00e3o do funcionamento do descompactador XZ. O backdoor era ativado no n\u00edvel do sistema de compila\u00e7\u00e3o, e o pr\u00f3prio c\u00f3digo-fonte do XZ coincidia com o c\u00f3digo do reposit\u00f3rio. Os macros m4 que ativavam o backdoor para a ferramenta Automake foram inclu\u00eddos apenas no arquivo pronto com o c\u00f3digo e estavam ausentes no reposit\u00f3rio. <\/p>\n
O backdoor no XZ foi inserido por um invasor que conseguiu o status de mantenedor do projeto. A inje\u00e7\u00e3o do backdoor foi imediatamente n\u00e3o percebida uma vez que as distribui\u00e7\u00f5es, em sua maioria, comp\u00f5em pacotes carregando o c\u00f3digo de arquivos prontos, pois ao carregar o c\u00f3digo para a compila\u00e7\u00e3o pode-se utilizar apenas uma soma de verifica\u00e7\u00e3o para verificar a integridade do arquivo do arquivo e usar espelhos. A aten\u00e7\u00e3o principal ao verificar o c\u00f3digo est\u00e1 concentrada na an\u00e1lise do conte\u00fado do reposit\u00f3rio, portanto, diferen\u00e7as n\u00e3o \u00f3bvias nos arquivos nem sempre podem ser detectadas imediatamente. <\/p>\n
Para simplificar a verifica\u00e7\u00e3o da conformidade entre arquivos de arquivos e cortes do reposit\u00f3rio, correspondentes a lan\u00e7amentos, alguns projetos de c\u00f3digo aberto, como PostgreSQL, implementaram um sistema de gera\u00e7\u00e3o repet\u00edvel de arquivos. Nesse caso, \u00e9 fornecido um conjunto de ferramentas que permite compilar seu pr\u00f3prio arquivo a partir do c\u00f3digo, correspondendo exatamente ao arquivo dispon\u00edvel para download. Se o arquivo criado de forma independente e o arquivo fornecido pelo projeto principal diferirem \u2014 h\u00e1 uma indica\u00e7\u00e3o de comprometimento do reposit\u00f3rio ou do arquivo de refer\u00eancia. <\/p>\n
O problema \u00e9 que esse m\u00e9todo \u00e9 praticado apenas em casos isolados, enquanto muitos projetos continuam a incluir artefatos adicionais nos arquivos de archive que est\u00e3o ausentes no reposit\u00f3rio principal, como p\u00e1ginas man, documenta\u00e7\u00e3o, exemplos, scripts de cria\u00e7\u00e3o de pacotes para distribui\u00e7\u00f5es e arquivos adicionais de constru\u00e7\u00e3o. Isso acontece principalmente por raz\u00f5es hist\u00f3ricas e pelas caracter\u00edsticas dos processos de forma\u00e7\u00e3o de lan\u00e7amentos. Uma simples verifica\u00e7\u00e3o da conformidade entre o conte\u00fado do reposit\u00f3rio e o arquivo nesse caso n\u00e3o \u00e9 adequada. <\/p>\n
Como solu\u00e7\u00e3o, foi proposto compilar arquivos bin\u00e1rios de lan\u00e7amento tanto a partir do reposit\u00f3rio (por exemplo, pode-se usar o arquivo gerado automaticamente no GitHub para a tag de lan\u00e7amento) quanto a partir do arquivo preparado pelo mantenedor, comparando em seguida os resultados. Como experimento, a inclus\u00e3o de tal verifica\u00e7\u00e3o foi proposta apenas para o pacote \u00abxz\u00bb. Se o experimento for bem-sucedido, as verifica\u00e7\u00f5es dever\u00e3o ser utilizadas tamb\u00e9m em outros pacotes no nixpkgs. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"