Relatório de auditoria do Homebrew

 (blog.trailofbits.com)
1 pontos por GN⁺ 2024-07-31 | 1 comentários | Compartilhar no WhatsApp
  • A auditoria da Trail of Bits confirmou no Homebrew, o gerenciador de pacotes de fato padrão do ecossistema de desenvolvedores macOS, a possibilidade de execução inesperada de código e enfraquecimento da integridade de builds, embora os achados não tenham sido classificados como críticos
  • O escopo incluiu o Homebrew/brew com a CLI brew, além de Homebrew/actions, Homebrew/formulae.brew.sh e Homebrew/homebrew-test-bot, examinando em conjunto a fronteira entre o gerenciador de pacotes local e o CI/CD
  • Os problemas no lado do brew incluíram injeção de string na configuração do sandbox, colisão de namespace baseada em MD5, inclusão de recursos de rede não declarados, pivot por socket no macOS, abuso de token sudo e possibilidade de instalar formulae a partir de URLs não locais
  • No CI/CD, o gatilho pull_request_target e entradas workflow_dispatch não validadas podiam abrir caminho para adulteração na build de bottle, exposição de credenciais, elevação de privilégio e persistência em runners self-hosted do GitHub Actions
  • O Homebrew parte da premissa de formulae confiáveis, mas como a própria formula é código Ruby executável e a superfície de API e CLI é ampla, é difícil manter de forma consistente os limites de isolamento e integridade

Escopo e alvo da auditoria

  • A Trail of Bits realizou uma auditoria do Homebrew no verão passado
  • A auditoria abrangeu Homebrew/brew, que contém a CLI brew, e três repositórios adjacentes críticos para a segurança
  • A Open Tech Fund patrocinou a auditoria como parte de seu trabalho para reforçar a segurança de componentes essenciais da infraestrutura da internet
  • O relatório completo pode ser consultado no repositório de publicações da Trail of Bits

Por que o Homebrew é importante

  • O Homebrew se apresenta como “o gerenciador de pacotes que faltava para macOS ou Linux” e atua, na prática, como o gerenciador de pacotes padrão para desenvolvedores macOS
  • Ele processa centenas de milhões de instalações de pacotes por ano, incluindo pacotes essenciais como Golang, Node.js e OpenSSL
  • A integridade de build desses pacotes afeta a segurança não só do Homebrew, mas também de ecossistemas de software dependentes
  • O núcleo do Homebrew é um monólito em Ruby que fornece a CLI brew e uma API Ruby reutilizável
  • Desde seu início em 2009, o Homebrew mudou sua estrutura várias vezes para aumentar a confiabilidade e a usabilidade dos pacotes
    • Introduziu os builds binários chamados bottle
    • Passou a usar bottles como método padrão de instalação no lugar do build local a partir do código-fonte
    • Restringiu a criação de bottles ao CI/CD para reduzir o impacto de máquinas de desenvolvedores comprometidas
  • Embora o método de instalação tenha se tornado cada vez mais estático, o código central ainda carrega uma estrutura histórica de carregamento dinâmico de formulae baseadas em DSL por meio de código Ruby controlado pelo usuário

Limites de ataque observados na auditoria

  • Foi verificado se um agente local poderia induzir execução inesperada da DSL de formula sem um brew install explícito
  • Também foi analisado se a simples execução de brew tap por um usuário poderia provocar a avaliação inesperada de formulae de um tap
  • Foi investigado se brew install foo poderia ser levado a instalar uma formula diferente da esperada por meio de confusão ou colisão de namespace
  • Também foi verificado se uma formula instalada localmente poderia contornar de forma discreta ou enfraquecer os mecanismos de isolamento de build do Homebrew
  • No CI/CD, as questões centrais eram se um agente com poucos privilégios poderia pivotar para um contexto com mais privilégios, contaminar builds de bottle ou estabelecer persistência

Problemas encontrados na CLI brew

  • Na base de código da CLI brew, foram encontrados problemas que podem enfraquecer as propriedades de integridade e isolamento por formula
  • Também foram identificados caminhos pelos quais formulae podem ser carregadas a partir de fontes inesperadas, como URLs remotas
  • Os principais achados foram os seguintes
    • TOB-BREW-2: uma formula pode alterar a configuração do sandbox por injeção de string, o que pode levar a escape do sandbox
    • TOB-BREW-5: o Homebrew usa uma função hash MD5 sujeita a colisões no namespace sintético FormulaNamespace, permitindo que um atacante induza confusão em tempo de execução entre formulae
    • TOB-BREW-8: uma formula pode incluir discretamente recursos de rede na build sem declará-los na stanza resource
    • TOB-BREW-11: uma formula pode sair do sandbox de build no macOS usando pivot por socket
    • TOB-BREW-12: uma formula pode realizar elevação oportunista de privilégio por meio de um token sudo previamente ativo do usuário
    • TOB-BREW-13: brew install pode ser induzido a instalar formulae a partir de URLs não locais usando qualquer protocolo suportado pela versão de curl em uso, como SFTP e SCP
  • O Homebrew/brew é amplamente testado, mas sua grande superfície de API e CLI, somada a contratos informais de comportamento local, deixa espaço para que atacantes encontrem caminhos de execução de código local fora do sandbox
  • Esses caminhos não necessariamente quebram a principal premissa de segurança do Homebrew, que assume formulae confiáveis, mas podem ser explorados com formulae maliciosas ou carregamento inesperado de formulae por meio de entradas insuficientemente tratadas

Problemas encontrados no CI/CD do Homebrew

  • Também foram encontrados problemas nos workflows e nas actions do CI/CD do Homebrew que podem enfraquecer a integridade das execuções de CI/CD
  • Foi confirmada a possibilidade de usuários com poucos privilégios pivotarem para posições de maior privilégio ou obterem persistência em runners self-hosted do GitHub Actions do Homebrew
  • Os principais achados foram os seguintes
    • TOB-BREW-18: vários workflows de CI/CD usavam o gatilho pull_request_target, permitindo que pull requests de terceiros executassem código no contexto dos repositórios upstream do Homebrew, o que pode levar à exposição de credenciais ou adulteração de builds de bottle
    • TOB-BREW-23: vários workflows de CI/CD permitiam injeção de shell por meio de entradas workflow_dispatch não validadas, o que pode permitir movimentação vertical de usuários com poucos privilégios que não podem modificar workflows, mas conseguem executá-los
  • Além dos problemas específicos de CI/CD, alguns achados relacionados ao brew também eram relevantes nesse ambiente
    • TOB-BREW-6: a falta de sandboxing e isolamento durante a extração de arquivos compactados pode permitir que um agente de CI com poucos privilégios induza a extração de formulae ou código executável carregado e executado automaticamente, pivotando para um contexto mais privilegiado
    • TOB-BREW-13: pode ser explorado para fazer o CI instalar com brew install uma formula que não esteja no contexto de confiança pré-configurado, resultando em execução arbitrária de código e pivot de privilégios
  • O CI/CD do Homebrew é maduro e eficaz em reduzir pontos de intervenção humana no ciclo de vida dos pacotes, mas depende de padrões de uso vulneráveis comuns em workflows do GitHub Actions
    • gatilhos de workflow arriscados
    • mistura de configuração, código e dados por meio de expansão de templates
  • Esses padrões não necessariamente permitem persistência ou pivot completos por um agente totalmente externo, mas podem ser aproveitados por um insider de poucos privilégios, como um rogue maintainer, para enfraquecer as premissas de integridade e isolamento do CI/CD

Por que auditorias de gerenciadores de pacotes são difíceis

  • Ecossistemas de gerenciadores de pacotes como o Homebrew são difíceis de delimitar em uma auditoria porque, por definição, instalam e executam código arbitrário de terceiros
  • A distinção entre execução de código esperada e inesperada também costuma ser informal e definida de forma frouxa
  • No Homebrew, esse problema fica ainda mais evidente porque a própria formula é código Ruby executável
  • Durante a auditoria, houve colaboração estreita com os maintainers do Homebrew, a Homebrew PLC e o administrador de segurança do Homebrew, Patrick Linnane

Leituras relacionadas

1 comentários

 
GN⁺ 2024-07-31
Comentários no Hacker News

  • Sou o autor deste texto e uma das pessoas que participaram da auditoria, então posso responder a perguntas
    Se estiver difícil encontrar o relatório de auditoria em si por ser um link indireto, deixo uma cópia aqui também: https://github.com/trailofbits/publications/blob/eb9344f2261...

  • Excelente trabalho; era exatamente esse tipo de revisão sistemática que eu vinha procurando em uma solução open source como essa
    Talvez não seja o foco da revisão de código, mas tenho curiosidade sobre a visão de vocês a respeito dos problemas gerais de ciclo de vida da cadeia de suprimentos inerentes a uma plataforma open source de gerenciamento de pacotes. O ponto central é se os procedimentos de validação garantem adequadamente que uma nova formula aponte para a fonte original correta, como os usuários podem ter certeza de que brew update ainda referencia uma origem confiável, o que acontece se um domínio for sequestrado e com que rapidez a equipe consegue reagir a uma origem não confiável em uma formula
    Nem todos esses problemas são coisas que o Homebrew precisa resolver, mas são considerações importantes no nível do ecossistema. O winget e o choco têm os mesmos problemas, e eles são menores em repositórios com suporte comercial, como apt ou yum. Pessoalmente, e para muitos administradores, isso também é uma grande preocupação ao lidar com a Windows Store
    Por fim, se a equipe do Homebrew estiver lendo, seria muito bom ter alertas de vulnerabilidade no estilo npm

    • Esse problema é realmente sério, especialmente quando um gerenciador de pacotes é usado em ambientes de produção ou pipelines de CI/CD
      Há casos públicos suficientes de pessoas ligadas ao Partido Comunista Chinês conseguindo permissão de pull request em pacotes essenciais, e acredito que existam ainda mais casos não divulgados ou encobertos. Só o fato de a propriedade de um pacote passar de uma entidade respeitável para um indivíduo menos conhecido já é, naturalmente, motivo de preocupação
      Como alguém que passou de engenheiro de software/gerente de engenharia para VC, fico curioso para saber se há startups ou empresas comerciais oferecendo esse tipo de garantia. Ao mesmo tempo, temo que o mercado para resolver esse problema talvez não seja grande o suficiente para sustentar um negócio independente

  • Antes de migrar para o Nix, eu usava MacPorts porque o Homebrew, na época, se comportava de uma forma bem peculiar. Não funcionava em configurações multiusuário, tomava posse de /usr/local, e a falta de atualizações automáticas e de controle de versões causava muitos problemas do tipo “funciona na minha máquina”
    O que sempre me deixou inseguro no Homebrew não era o Git, mas o fato de ser possível usar uma URL do GitHub como se fosse um pacote temporário. Fico me perguntando se o TOB-BREW-13 funcionou dessa maneira. Esse recurso sempre pareceu um incidente de segurança esperando para acontecer
    De qualquer forma, eu também gostaria de ver uma auditoria do Nix no macOS. Tenho curiosidade especialmente sobre se há falhas no modo como nix develop e comandos relacionados funcionam

    • Engraçado, eu também migrei na ordem Homebrew -> MacPorts -> Nix
      O Homebrew coletava analytics e as versões quebravam com frequência demais. O MacPorts é muito mais estável, mas alguns pacotes de nicho não compilavam bem e havia problemas de terminfo no tmux
      O Nix permite sobrescrever a maior parte disso, e é bom poder compartilhar a configuração do home manager com uma workstation Debian
    • No macOS, o Nix não usa sandbox de build por padrão. É possível ativá-lo manualmente colocando sandbox = true em nix.conf, mas isso pode quebrar várias coisas
      Na verdade, a sandbox do Nix também não foi projetada como uma fronteira de segurança. Não há esforço para impedir escapes da sandbox, e muitas coisas do host vazam para o ambiente da sandbox. Para compilar pacotes não confiáveis, seria necessário algo como gVisor ou uma VM completa
    • O Nix também permite github

  • Dei uma olhada rápida no bug de escape da sandbox e na correção relacionada: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7...
    Fico em dúvida se isso está certo. Parece que estão tentando evitar que algo seja interpolado no perfil da sandbox e cause problemas, mas não sei quanta confiança dá para ter nessa lista de caracteres

    • A mensagem do commit poderia ter respondido a essa pergunta, mas na prática ela só repete o que o diff já mostra: “não permitir caracteres especiais em caminhos de regras da sandbox”
      Ela não explica o porquê nem o que há de especial nos caracteres específicos proibidos. Uma mensagem melhor teria algo como: “bloqueia certos caracteres em caminhos porque, caso contrário, ... Esses caracteres precisam ser considerados, mas os outros estão ok porque ...”
      Mesmo que você saiba o que está fazendo agora ao escrever esse código, daqui a um ano, ao olhar de novo, vai ficar coçando a cabeça tentando lembrar por que essa alteração foi feita
      Um exemplo real de boa mensagem de commit está aqui: https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...
    • Se essa é a correção, eu também ficaria surpreso. Uma lista de permissões não seria melhor do que uma lista negra?

  • Há algum tempo troquei o brew pelo nix, e a UI de texto poderia ser mais amigável para o usuário final
    Por isso até criei um wrapper chamado “ixnay” para conseguir fazer ixnay install tão facilmente quanto no brew (https://github.com/pmarreck/ixnay), mas as garantias gerais valem a pena

    • Eu também acho a linha de comando do nix irritante. Vou experimentar isso. Gosto da documentação #help embutida
    • Queria ter conhecido o ixnay antes. Eu também fiquei irritado com a experiência de uso e acabei criando minha própria ferramenta, chamada hdn: https://github.com/seasonedfish/hdn
      Mencionei o ixnay no README

  • É um pouco surpreendente que a integridade da cadeia de suprimentos, que é uma grande superfície de ataque de baixa qualificação do Homebrew em comparação com quase todos os gerenciadores de pacotes do Linux e do *BSD, não tenha sido tratada de forma significativa
    Os mantenedores do Homebrew, em geral, não assinam commits/pacotes, não assinam revisões/merges, não verificam assinaturas de autores/revisores na compilação, não reproduzem builds em uma CI com controles separados e não exigem autenticação de dois fatores via hardware no GitHub
    O nível de segurança dos usuários do brew fica atrelado ao nível da pessoa que tiver a pior segurança operacional naquele dia entre as centenas de mantenedores do brew
    Além disso, como o dependabot cria commits automaticamente, alguém poderia colocar um commit malicioso em um projeto externo sob seu controle, esperar até o dependabot criar um commit de upgrade no Homebrew e então fazer o merge pessoalmente. Para se tornar mantenedor do Homebrew, praticamente não há verificação, e basta corrigir alguns bugs fáceis
    Também seria possível assumir um domínio de e-mail expirado de um mantenedor, enviar e-mails de redefinição de senha para si mesmo e tomar a conta de alguém que esteja de férias ou afastado
    É muito provável que dê para comprometer milhares de empresas antes que alguém perceba
    Sinceramente, eu nunca permitiria Brew em equipamentos corporativos com privilégios. Isso equivale a dar a centenas de pessoas aleatórias, e a qualquer um que explore a segurança operacional frágil delas, a capacidade de executar código arbitrário no sistema do usuário
    Os principais gerenciadores de pacotes do Linux também não foram longe o bastante em pontos como assinatura de revisão, mas a maioria ao menos faz assinatura de pacotes no nível do autor, revisão humana e builds reproduzíveis independentes para muitos pacotes
    Considerando que alvos de alto valor, como administradores de sistemas corporativos, muitas vezes permitem brew em seus computadores, o Brew está no caminho para superar a Crowdstrike a qualquer momento em termos de danos causados por gerenciamento da cadeia de suprimentos insuficiente

  • Se o Mac desse suporte a PKGBUILD como o Pacman, com desempenho semelhante, e os pacotes dos programas essenciais fossem mantidos corretamente, acho que haveria muito menos concessões a aceitar por conveniência ao usar um Mac
    O Homebrew é excelente e as formulae são realmente muito bem mantidas, mas, pela simplicidade do PKGBUILD, pela sincronização rápida e pela menor carga cognitiva de ter que lembrar vários argumentos e flags em diferentes gerenciadores de pacotes, eu gostaria que o pacman simplesmente funcionasse no Mac

  • Acho que o principal vetor de ataque é simplesmente contribuir com uma nova formula e enfiar discretamente um novo pacote malicioso
    A equipe de mantenedores é pequena demais para auditar todas as formulae recém-contribuídas. É surpreendente que esse vetor de ataque não tenha sido incluído na auditoria

    • Acho que os revisores atuais das formulae do Homebrew core não considerariam sua equipe pequena demais para revisar adequadamente as novas solicitações de formulae
      Mesmo que fosse o caso, isso é uma das ambiguidades de empacotamento tratadas explicitamente no texto. A fronteira entre execução de primeira parte e de terceiros é inerentemente nebulosa e, em vez de apontar todas as coisas óbvias que acontecem quando alguém executa intencionalmente código de terceiros, vejo relativamente mais valor de segurança em encontrar pontos em que a execução de terceiros pode acontecer em lugares inesperados
      Dito isso, acho que o ecossistema de empacotamento como um todo deveria ser avaliado quanto a esse tipo de processo de aprovação. Mas, como isso diz respeito a procedimentos humanos, está mais próximo de uma auditoria no estilo red team do que de uma auditoria de software
    • Essa parte foi anotada, e foi assumido que as formulae são confiáveis
      “... These avenues do not necessarily violate Homebrew’s core security assumptions (which assume trustworthy formulae),...”
    • Eu também me assustei há alguns dias ao ver alguém baixando um emulador de console chamado “Cmder”. Era uma coleção de várias ferramentas FOSS e continha literalmente cerca de 1.000 arquivos potencialmente maliciosos, como scripts PowerShell, scripts Perl, scripts Python, shell scripts, DLLs, EXEs etc.
      No fim, era inofensivo, mas é realmente assustador que as pessoas simplesmente clonem repositórios Git assim e torçam para dar certo

  • Havia vários itens TOB-BREW-n listados, e fiquei pensando se seriam algo como números CVE específicos desse projeto
    Edit: ah, era “Trail Of Bits - homeBREW”. Ainda assim, provavelmente é isso mesmo

    • Sim. Nos resultados de auditoria usamos a convenção TOB-$PRODUCT-$XXXX. $PRODUCT é o alvo da auditoria, e $XXXX é um contador incremental único para cada descoberta
      Pelo que sei, muitas empresas de auditoria usam uma abordagem parecida

  • A redação deste post do blog é um pouco confusa. Ele diz que a auditoria foi feita junto com o Homebrew, mas o nome me pareceu familiar; ao verificar o README do Homebrew, vi William Woodruff na lista de mantenedores em https://github.com/Homebrew/brew
    Fico curioso se há algum motivo para isso não ter sido mencionado no post do blog. Não acho que faça muita diferença, mas gostaria de esclarecer

    • Eu não era mantenedor na época em que fizemos a auditoria :-)
      Por muito tempo fui um “membro” não mantenedor do projeto, uma posição meio honorária dada a ex-mantenedores que querem continuar participando das conversas internas e da governança. Depois, alguns meses após a conclusão da auditoria, recebi novamente a oferta de associação por causa de outro trabalho relacionado ao Homebrew, que nem existia nem estava planejado antes do planejamento da auditoria
      Isso foi incluído em todas as divulgações de conflito de interesses que fiz tanto à empresa quanto aos mantenedores do Homebrew, mas concordo que também pode ser explicitado no post do blog. Vou tentar adicionar isso hoje
      Em resumo: no momento da auditoria, eu não era mantenedor, mas já tinha sido mantenedor antes e atualmente também sou mantenedor. A auditoria foi conduzida por mim e pelos meus colegas como trabalho profissional