NGINX Rift - novo exploit para NGINX

• NGINX Rift é uma PoC de execução remota de código para CVE-2026-42945, um heap buffer overflow crítico no ngx_http_rewrite_module do NGINX
• Essa vulnerabilidade permite execução remota de código sem autenticação em servidores que usam as diretivas rewrite e set
• O problema vem de um bug introduzido em 2008, causado pelo fato de o passo de cálculo de comprimento e o passo de cópia do mecanismo de scripts do NGINX tratarem a flag is_args de forma diferente
• Quando a string de substituição de rewrite contém ?, is_args é definido no mecanismo principal, mas o cálculo de comprimento é executado em um submecanismo recém-inicializado com 0 e retorna apenas o comprimento da captura original
• Na etapa de cópia, ngx_escape_uri e NGX_ESCAPE_ARGS são chamados com is_args = 1, fazendo com que cada byte escapável se expanda para 3 bytes e permitindo que dados de URI controlados pelo atacante estourem o heap buffer subalocado
• O exploit usa heap feng shui entre requisições para corromper o ponteiro cleanup de um ngx_pool_t adjacente e, como não é possível inserir bytes nulos no URI, faz spray pelo corpo do POST
• O ponteiro corrompido é redirecionado para um ngx_pool_cleanup_s falso e configurado para chamar system() durante a destruição do pool
• Junto com a CVE-2026-42945, outros 3 problemas de corrupção de memória — CVE-2026-42946, CVE-2026-40701 e CVE-2026-42934 — também foram descobertos autonomamente pelo sistema de análise de segurança da depthfirst com uma única incorporação do código-fonte do NGINX
• As versões afetadas são NGINX Open Source 0.6.27–1.30.0 e NGINX Plus R32–R36; as versões corrigidas são Open Source 1.31.0/1.30.1 e Plus R36 P4/R35 P2/R32 P6
• O aviso completo do fornecedor está em https://my.f5.com/manage/s/article/K000160932, e os detalhes técnicos são abordados no technical write-up
• A PoC foi testada no Ubuntu 24.04.3 LTS e fornece o fluxo ./setup.sh, docker compose -f env/docker-compose.yml up, python3 poc.py --shell para subir um contêiner vulnerável do NGINX e executar um shell

[GN⁺]

Opiniões no Hacker News

• Como responsável por segurança, cansa ver tanta gente afirmar ou insinuar que esse problema é muito menos assustador só porque o exploit divulgado não faz bypass de ASLR
  O texto original afirma que há uma forma confiável de contornar o ASLR nesse ataque, e considero razoável acreditar nisso como hipótese padrão mesmo sem prova
  ASLR é apenas uma técnica de defesa em profundidade que torna a exploração mais difícil e, na maioria dos casos, com tempo e habilidade, acaba surgindo um bypass de ASLR
  Por causa de agentes de LLM, essa barreira de tempo e habilidade também está ficando mais baixa a cada poucas semanas, então é só questão de tempo até aparecer um exploit totalmente armado, que pode ser publicado ou pode continuar privado
  Dizer “se o ASLR está ativado, então não há risco” é claramente errado, e é muito prejudicial para quem acredita nisso
  A falsa crença de que vulnerabilidades de segurança podem ser ignoradas porque técnicas de mitigação podem dificultar o exploit já causou muito dano no passado
  É bom que existam mitigações modernas, mas é preciso aplicar o patch o mais rápido possível e, se você é o fornecedor, não trate um relatório de vulnerabilidade como inválido só porque o pesquisador não apresentou um bypass de ASLR; corrija a causa raiz

  • Vulnerabilidades acessíveis remotamente não devem ser tratadas com leveza
    Dito isso, por enquanto os pré-requisitos parecem um pouco específicos
    Em 10 anos usando nginx em várias configurações, nunca usei rewrite e set juntos nem uma vez
  • Dá para assumir com segurança que as pessoas que dizem “a IA vai resolver cyber” e as que dizem “se o ASLR está ligado, está tudo bem” se sobrepõem numa proporção de 1:1
    E sempre falam “cyber” mesmo
  • Não concordo com esse ponto de vista, ou pelo menos eu o colocaria de outra forma
    ASLR é como uma senha extra que precisa ser adivinhada, tem uma certa entropia e normalmente é estável
    Se a vulnerabilidade não tiver uma parte de vazamento de informação, o ASLR pode mitigar completamente essa vulnerabilidade, ou então será necessária uma segunda vulnerabilidade
    Essa é outra discussão
    O ASLR pode mitigar completamente vulnerabilidades individuais, mas não consegue impedir uma cadeia de exploits
    Ainda assim, para convencer as pessoas a aplicar o patch rápido, eu preferiria usar como argumento a possibilidade de uma segunda vulnerabilidade que gere vazamento de informação
    Cadeias de exploit são perigosas em todo tipo de vulnerabilidade
  • É difícil impedir a propagação de informação errada na internet, e a maioria nem sabe que está errada
    O realmente nocivo é acreditar cegamente em comentários aleatórios da internet ditos com convicção
    Desenvolver a capacidade de perceber isso ajuda não só em segurança, mas em outras áreas também
  • Quando leio um relatório de execução remota de código em software exposto na internet pública, normalmente faço upgrade em poucos minutos
    É por isso que leio esse tipo de relatório, e ele deve ser levado a sério
    Caso contrário, a máquina vai ser comprometida em breve
    Ultimamente, parece que muitos exploits públicos de execução remota de código estão sendo divulgados sem aviso prévio, e eu gostaria que pelo menos dessem alguns minutos para atualizar o software
    Parece a época do fim dos anos 1980 e começo dos anos 1990, quando bugs exploráveis remotamente no sendmail apareciam em enxurrada e não havia nenhuma proteção no processo de divulgação
    Se você não lê esse tipo de relatório, ou lê tarde demais, milhões de máquinas podem ser comprometidas
    Hoje o nginx responde por cerca de 39% a 43% do mercado público de servidores web, então isso é bem sério

• Esse caso é bem ruim, mas há pré-condições
  É preciso uma diretiva rewrite com um ponto de interrogação na string de substituição, seguida por uma diretiva set que referencie um grupo de captura de regex
  Ex.: set $var $1
  Além disso, a prova de conceito assume o ASLR desativado

  • Exemplo: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
  • Existe alguma distribuição que desative ASLR por padrão?
    Mesmo desligando manualmente, nginx não seria o primeiro candidato que me viria à cabeça
  • Hoje em dia quase ninguém usa rewrite, não?
    Parece coisa da época antiga de PHP e Apache

• A página oficial da F5 está aqui: https://my.f5.com/manage/s/article/K000161019
  Como já foi dito em outros lugares, o ASLR oferece proteção
  Como mitigação enquanto se espera pelas versões corrigidas nas plataformas afetadas, a orientação é “usar capturas nomeadas em vez de capturas sem nome nas definições de rewrite”
  A ideia é: “para mitigar a vulnerabilidade neste exemplo, troque $1 e $2 pelas capturas nomeadas apropriadas $user_id e $section”
  A F5 corrigiu as versões 1.31.0 e 1.30.1
  O OpenResty tem patches para 1.27 e 1.29: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
  O andamento do OpenResty, servidor de aplicações Lua baseado em Nginx, pode ser acompanhado aqui: https://github.com/openresty/openresty/issues/1119

• A prova de conceito desativa o ASLR: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

  • Os processos worker são criados com fork a partir do master, então recebem o mesmo layout de memória
    É possível causar crash nos workers sem limite
    Há grande chance de que isso permita construir um oráculo de leitura
    No mínimo, um DoS estável parece possível
    Análise completa da Depth First: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

• Existe alguma boa alternativa a Apache e Nginx que seja escrita em linguagem com segurança de memória e não tenha muitos buracos de segurança?
  Dei uma olhada rápida no Jetty, escrito em Java, e no Caddy, escrito em Go, mas não tenho certeza se são realmente melhores, já que o Jetty tem histórico de outros tipos de vulnerabilidade, como injeção de shell

  • Segurança de memória é bom, mas não impede todas as ameaças
    Hoje os operadores de infraestrutura deveriam se familiarizar com defesa ativa, como MAC, isto é, SELinux e AppArmor
    Antigamente havia muito atrito, mas agora existem mais ferramentas para facilitar o uso
    https://presentations.nordisch.org/apparmor/
    https://github.com/nobody43/apparmor-profiles/blob/master/ng...
    https://github.com/nobody43/apparmor-suggest
    Só para constar, os dois repositórios são meus
  • Em software usado na escala de Apache e nginx, é inevitável haver um histórico de vulnerabilidades
    O fato de ambos manterem participação de mercado por tanto tempo é, na verdade, um bom sinal
  • O Caddy foi realmente muito agradável de usar
    Só não gosto muito do modelo em que, em vez de um sistema de plugins de verdade, acabam existindo milhares de binários conforme a combinação de plugins que você quer
    Ainda assim, se você compilar a partir do código-fonte, ele é bem limpo e simples
  • Apache e provavelmente o Nginx também têm uma enorme quantidade de recursos e componentes
    A maioria dos servidores HTTP alternativos reduz bastante o escopo, então primeiro é preciso decidir de quais recursos você precisa
    Não vejo muita discussão sobre servidores HTTP em linguagens com segurança de memória
    Os três grandes servidores em C — Apache, Nginx e lighttpd — são todos bastante sólidos, e não parece haver muita gente querendo migrar para um projeto novo só por causa da linguagem
    Além disso, ao escolher a maioria das linguagens com segurança de memória, você também aceita o runtime, a máquina virtual e componentes adicionais daquela linguagem, que às vezes são enormes
    Num servidor web Java, há chance de usarem log4j, como costuma acontecer em projetos Java aleatórios
  • Para uso como load balancer, o HAProxy está indo muito bem

• “O exploit usa heap feng shui entre requisições (cross-request heap feng shui)”, é a primeira vez que vejo feng shui ser usado desse jeito

• Isso já foi corrigido no Debian 12?
  Ainda assim, dá para dizer que, se você não usa rewrite nem set em lugar nenhum, então não é afetado?

  • https://security-tracker.debian.org/tracker/CVE-2026-42945
  • O Ubuntu já estava corrigido hoje de manhã
    Não parece que o Debian tenha corrigido o trixie ainda
  • Parece muito raro usar nginx sem usar pelo menos set
    A maioria dos casos de uso de nginx é terminar TLS e encaminhar requisições para node/php/go etc.
    Então eu imaginei que deveria haver ao menos um set com dados controlados por atacante em alguma linha como proxy_set_header X-Host $host;
    Correção: parece que capturas nomeadas não são afetadas
    Se não houver $1 em algum lugar, provavelmente está tudo bem

• Link melhor:
  https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
  https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)