Para inclusão no repositório de pacotes nixpkgs, utilizado na distribuição NixOS, foi proposto um modo de compilação repetível, que permite identificar casos de injeção de backdoors no código, semelhante ao incidente com o projeto XZ. O método de proteção apresentado permite detectar modificações nos arquivos de código-fonte de lançamentos que não estão presentes nos repositórios de código.
A essência do método é que o código-fonte da nova versão do aplicativo é compilado duas vezes — a primeira a partir do código carregado do repositório git, e a segunda a partir do código distribuído em arquivos prontos. Se os arquivos binários resultantes das compilações diferem, isso levanta suspeitas de que haja modificações ocultas no repositório ou no arquivo de código.
Lembramos que, no caso do projeto XZ, o repositório de código não continha alterações suspeitas. Os componentes maliciosos que formavam o backdoor eram fornecidos dentro de arquivos usados no conjunto de testes para verificar a correção do funcionamento do descompactador XZ. O backdoor era ativado no nível do sistema de compilação, e o próprio código-fonte do XZ coincidia com o código do repositório. Os macros m4 que ativavam o backdoor para a ferramenta Automake foram incluídos apenas no arquivo pronto com o código e estavam ausentes no repositório.
O backdoor no XZ foi inserido por um invasor que conseguiu o status de mantenedor do projeto. A injeção do backdoor foi imediatamente não percebida uma vez que as distribuições, em sua maioria, compõem pacotes carregando o código de arquivos prontos, pois ao carregar o código para a compilação pode-se utilizar apenas uma soma de verificação para verificar a integridade do arquivo do arquivo e usar espelhos. A atenção principal ao verificar o código está concentrada na análise do conteúdo do repositório, portanto, diferenças não óbvias nos arquivos nem sempre podem ser detectadas imediatamente.
Para facilitar a verificação da conformidade entre os arquivos de arquivo e os snapshots do repositório correspondentes aos lançamentos, alguns projetos abertos, como o PostgreSQL, introduziram um sistema de geração repetível de arquivos de archive. Neste caso, é fornecida uma ferramenta que permite que você crie seu próprio arquivo a partir do código, totalmente correspondente ao arquivo pronto disponível para download. Se o arquivo criado independentemente e o arquivo fornecido pelo projeto principal forem diferentes, isso indica uma comprometimento do repositório ou do arquivo de referência.
O problema é que esse método é praticado apenas em casos isolados, enquanto muitos projetos continuam a incluir artefatos adicionais nos arquivos de archive que estão ausentes no repositório principal, como páginas man, documentação, exemplos, scripts de criação de pacotes para distribuições e arquivos adicionais de construção. Isso acontece principalmente por razões históricas e pelas características dos processos de formação de lançamentos. Uma simples verificação da conformidade entre o conteúdo do repositório e o arquivo nesse caso não é adequada.
Como solução, foi proposto coletar os arquivos binários do lançamento tanto do repositório (por exemplo, pode-se usar o arquivo gerado automaticamente no GitHub para a tag de lançamento) quanto do arquivo preparado pelo responsável, comparando o resultado em seguida. Como experimento, a inclusão dessa verificação foi proposta apenas para o pacote 'xz'. Se o experimento for bem-sucedido, a verificação deverá ser usada também em outros pacotes no nixpkgs.
Fonte: opennet.ru
