AWS FPGA SDK dava caminho ao root — atualize e revise forks
A AWS divulgou em 3 de setembro de 2026 uma falha de escalada local de privilégios no componente de instalação das ferramentas de gerenciamento do AWS FPGA Developer Kit. O boletim de segurança da AWS confirma que versões anteriores à 2.3.4 podem executar como root conteúdo de shell colocado por um usuário local em um caminho temporário previsível.
A correção já está disponível na versão 2.3.4: o kit deixou de transportar uma função pelo arquivo /tmp/sdk_root_env.exp. Além de atualizar instalações oficiais, a AWS recomenda incorporar a mudança a forks e código derivado, nos quais os scripts antigos podem continuar presentes mesmo depois da atualização do repositório de origem.
O arquivo previsível atravessava a barreira de privilégios
A falha dependia de acesso local ao mesmo host. O script install_fpga_mgmt_tools.sh elevava os próprios privilégios e carregava incondicionalmente /tmp/sdk_root_env.exp, localizado no diretório /tmp, sem verificar previamente a existência, o proprietário ou as permissões do arquivo.
Com isso, uma conta sem privilégios poderia criar ou substituir o arquivo e inserir comandos de shell. Se um administrador executasse depois a etapa de instalação, o conteúdo controlado por essa conta seria interpretado como root. O advisory GHSA-g4hc-wrmm-2x74, publicado em 10 de agosto, descreve esse encadeamento e classifica a vulnerabilidade com vetor local.
Não se trata, portanto, de execução remota direta contra uma instância F2. O cenário requer um usuário local capaz de manipular o caminho temporário e uma execução posterior do instalador vulnerável com privilégios elevados. O advisory também limita o problema ao script open source executado em hosts administrados pelo cliente: a infraestrutura gerenciada pela AWS para receber, validar e carregar Amazon FPGA Images não é afetada.
Versão declarada não basta para localizar todas as cópias
A faixa vulnerável é aws-fpga anterior à versão 2.3.4. Um registro independente da vulnerabilidade também relaciona a divulgação a 3 de setembro, identifica o vetor como local e aponta a atualização para a versão 2.3.4 como remediação.
O inventário precisa abranger mais do que clones vinculados a uma tag antiga. Scripts do kit podem ter sido copiados para repositórios internos, pipelines de provisionamento, imagens de máquina, pacotes próprios ou forks que já não acompanham diretamente o projeto oficial. Nesses casos, mudar uma dependência declarada ou atualizar outro checkout não altera o arquivo efetivamente executado no host.
A verificação mais direta é procurar pela referência literal a /tmp/sdk_root_env.exp, especialmente em sdk_setup.sh, install_fpga_mgmt_tools.sh e suas derivações. Também é necessário associar cada ocorrência aos artefatos implantados: uma imagem já construída pode conservar o instalador antigo mesmo quando o repositório usado em novos builds está corrigido.
A ausência do caminho em um checkout central, isoladamente, não demonstra que todo o ambiente foi atualizado. A evidência relevante é a combinação entre a versão do código implantado, os scripts presentes nas máquinas e a procedência das imagens ou dos pacotes usados pela automação.
A versão 2.3.4 remove o transporte por /tmp
Na implementação corrigida, foi removida de sdk_setup.sh a etapa que gravava a função allow_non_root em /tmp/sdk_root_env.exp. As ferramentas passaram a carregar essa função diretamente de shared/bin/set_common_functions.sh, eliminando do fluxo o arquivo previsível que podia ser preparado por outra conta local.
Para instalações que acompanham o projeto oficial, a resposta é atualizar para a versão 2.3.4 ou posterior e reconstruir imagens, pacotes e demais artefatos que incorporem o kit. A conferência deve alcançar os arquivos efetivamente usados na instalação, e não apenas o número de versão registrado no ambiente de desenvolvimento.
Quando a atualização imediata não for possível, o workaround publicado pela AWS é remover ou comentar as linhas que fazem referência a /tmp/sdk_root_env.exp em sdk_setup.sh e install_fpga_mgmt_tools.sh. A mitigação deve ser tratada como alteração temporária e substituída pelo código mantido assim que o ciclo de atualização permitir.
Forks exigem comparação de código e reconstrução
Em forks e cópias derivadas, alterar apenas um campo de versão pode produzir uma falsa indicação de segurança. O critério técnico é comprovar que o fluxo executado não grava nem carrega /tmp/sdk_root_env.exp e que a função necessária vem diretamente do arquivo compartilhado usado pela implementação corrigida.
- Identifique repositórios, pacotes, imagens e automações que contenham os scripts do AWS FPGA Developer Kit.
- Localize todas as referências a /tmp/sdk_root_env.exp e determine quais delas chegam aos hosts.
- Atualize para a versão 2.3.4 ou incorpore ao fork a remoção do fluxo temporário e o carregamento direto de shared/bin/set_common_functions.sh.
- Reconstrua os artefatos derivados e substitua as cópias antigas implantadas.
- Valide a instalação e confirme que nenhum processo elevado ainda carrega conteúdo daquele caminho temporário.
Se um fork divergiu muito do projeto original, a busca pelo nome exato continua útil, mas pode não encerrar a revisão. Como medida defensiva, também convém examinar qualquer ponto em que um processo privilegiado leia ou execute conteúdo de um diretório gravável por usuários sem privilégios; isso não significa que outros caminhos do kit tenham sido identificados como vulneráveis.
O estado confirmado é que a correção existe no projeto oficial e que o vetor depende de acesso local ao host administrado pelo cliente. O que não pode ser determinado pelo repositório público é quais forks, imagens antigas e automações externas já incorporaram a mudança; essa confirmação depende do inventário e da comparação mantidos por cada operador.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.