Nix e Lix: reprodutibilidade não torna uma descrição de build confiável

Nix e Lix divulgaram falhas que podem ser combinadas para elevar privilégios a root em sistemas com seus daemons.[7] A nota da LWN destaca a exposição de sistemas que constroem derivações não confiáveis e informa que releases corrigidos estão disponíveis.[7] A notícia exige separar duas propriedades que frequentemente são confundidas: reconstruir um ambiente de forma previsível e confiar no código que define esse ambiente.

O que muda para quem desenvolve

Um dos problemas compartilhados é um estouro de inteiro na alocação de listas durante a avaliação de código Nix não confiável.[7] Outro envolve operações de reparo por usuários sem privilégio que podiam destruir e substituir caminhos legítimos do store antes da validação.[7] Há ainda uma fuga de sandbox no macOS ligada à geração de um perfil Seatbelt sob condições específicas.[7]

A análise de engenharia começa antes do comando que produz o artefato. Se a avaliação da descrição já processa entrada externa, isolá-la apenas na execução final deixa uma etapa anterior fora do controle pretendido. Proponha desenhar avaliação, build, reparo e acesso ao daemon como operações separadas no modelo de permissões.

Nix também tinha um problema no instalador multiusuário que podia deixar o conteúdo inicial do store pertencendo ao usuário que executou a instalação, em vez de root.[7] Instalações NixOS não são afetadas por esse erro específico.[7] Corrigir o binário e revisar a propriedade do conteúdo devem ser critérios distintos.

Como aplicar

Faça um inventário de runners e máquinas de desenvolvimento: implementação usada, versão do daemon, origem das expressões avaliadas, usuários autorizados e permissões do store. Identifique quais etapas recebem contribuições externas sem revisão.

O aviso lista Nix 2.35.3, 2.34.9, 2.31.6, 2.30.6 e 2.28.8 como versões corrigidas, e Lix 2.94.3, 2.95.4 e 2.96.0.[7] Confira a linha utilizada e o caminho de atualização aplicável. Para canais NixOS, a distribuição dos backports precisa ser verificada, não presumida pela existência do release upstream.[7]

Em homologação, proponha comparar a execução de uma descrição benigna aprovada e de uma contribuição externa igualmente benigna. Registre identidade do processo, acesso ao daemon e caminhos graváveis. O experimento deve demonstrar a separação esperada, sem usar provas de exploração em infraestrutura compartilhada.

Para operações de reparo e restauração, exija validação antes de substituições destrutivas e evidência de propriedade correta depois da manutenção. O objetivo é testar a autorização do efeito, não apenas que o comando terminou.

Cuidados e limites

As linhas Nix 2.29, 2.32 e 2.33 não receberão essas correções, e Lix 2.93 e anteriores estão fora de manutenção no retrato do aviso.[7] O alcance das falhas varia conforme sistema, compilação e configuração da sandbox.[7]

Os IDs CVE ainda não haviam sido solicitados, e os identificadores provisórios não são CVEs válidos.[7] Evite inventar identificadores para preencher um scanner. Reprodutibilidade continua útil; ela precisa conviver com revisão de entrada, manutenção e isolamento, não substituí-los.

Fonte

[7] Fonte: LWN.net, com detalhes do aviso conjunto publicado no NixOS Discourse