NGINX corrige falhas que permitem executar código em servidores sem fazer login

O NGINX lançou em 14 de outubro as versões 1.30.6 (stable) e 1.31.7 (mainline) com correções para cinco vulnerabilidades. Três delas são falhas de memória que um atacante pode provocar com requisições HTTP manipuladas e sem fazer login. No pior caso, isso significa executar código no servidor. A F5, que desenvolve o NGINX, dá a essas três a nota 9,2 de 10 (crítica) no CVSS 4.0. Cada uma, porém, só pode ser explorada com uma configuração específica, então um servidor com NGINX não está exposto automaticamente. A F5 diz que não conhece nenhum exploit público nem ataques.

O que foi corrigido

As três falhas graves dependem de diretivas que são comuns em configurações reais:

Nos três primeiros casos, o estouro derruba um processo worker do NGINX, que depois reinicia. Requisições repetidas podem fazer isso acontecer o tempo todo, então no mínimo há uma negação de serviço. A execução de código, segundo a F5, é possível em sistemas com a randomização do espaço de endereços (ASLR) desativada ou em que o atacante consegue contorná-la. A falha do alias está no código desde a versão 0.1.29, lançada em 2005.

A falha dos tickets de sessão é de outro tipo. Uma das chaves rotacionadas ficou sem inicialização, e a F5 afirma que um atacante poderia forjar uma sessão TLS e usá-la para passar pela verificação de certificados de cliente. Isso importa para servidores que admitem pessoas por certificado, como painéis de administração e serviços internos.

Crítica ou média?

As duas classificações parecem se contradizer. Na página de avisos do nginx.org, as cinco falhas aparecem como "medium". Nos registros CVE da própria F5, as três falhas de memória recebem 9,2 no CVSS 4.0 e 8,1 (alta) no CVSS 3.1. A diferença vem das condições. O vetor CVSS diz que o ataque não exige conta, mas tem complexidade alta, porque só funciona em uma configuração compatível. O Security Affairs escreveu em 16 de outubro sobre onze problemas corrigidos. O número maior abrange mais do que o NGINX em si: no mesmo dia a F5 lançou atualizações para produtos relacionados, entre eles o módulo de script njs, o Ingress Controller e o Gateway Fabric.

Como verificar o seu servidor

O NGINX fica na frente de muitos serviços auto-hospedados em servidores alugados, como painéis de VPN e proxy, compartilhamentos de arquivos e sites pequenos. Se você administra um, dois comandos bastam para começar. nginx -v mostra a versão, e nginx -T | grep -nE 'alias|request_filename|aio|ssi |ssl_session_cache|ssl_session_ticket|map ' lista as diretivas da tabela em toda a configuração carregada.

O número da versão sozinho pode enganar. Debian e Ubuntu mantêm versões antigas do NGINX e aplicam patches de segurança nelas, então "1.22" ou "1.26" em um servidor não diz se as correções de outubro estão incluídas. Em 17 de outubro, o rastreador de segurança do Debian ainda listava os pacotes do bookworm e do trixie como vulneráveis. Consulte o rastreador da sua distribuição e atualize com apt update && apt upgrade quando surgir um pacote corrigido. Com os pacotes oficiais do nginx.org, as versões corrigidas são a 1.30.6 e a 1.31.7.

Até a correção chegar, a F5 aconselha mudar a configuração: evitar alias e $request_filename nos blocos afetados, usar capturas nomeadas no map em vez de $1 e $2, desativar o aio ou deixar de servir páginas SSI, e carregar as chaves de ticket de um arquivo com ssl_session_ticket_key ou desligar os tickets com ssl_session_tickets off. Nosso guia para proteger uma VPS cobre o resto da higiene básica de servidor.