CVE-2024-6387: regreSSHion — RCE no OpenSSH após 18 anos

Uma condição de corrida no manipulador de sinal do OpenSSH permite que invasores não autenticados executem código arbitrário como root em servidores Linux executando glibc. Apelidado de "regreSSHion" — uma regressão de CVE-2006-5051 que foi acidentalmente reintroduzida em 2020. Afeta aproximadamente 14 milhões de servidores SSH expostos à Internet. CVSS 8.1 ALTO.

O que é CVE-2024-6387?

CVE-2024-6387 é uma condição de corrida do manipulador de sinal no servidor OpenSSH (sshd). Quando um cliente não se autentica dentro do LoginGraceTime (padrão: 120 segundos), chamadas sshd SIGALRM para encerrar a conexão. O manipulador de sinal chama funções inseguras de sinal assíncrono - especificamente syslog() — que pode corromper o estado do heap quando chamado simultaneamente com outras operações.

Os pesquisadores da Qualys que descobriram a vulnerabilidade a chamaram de “regreSSHion” porque um bug idêntico (CVE-2006-5051) foi corrigido em 2006, mas a correção foi removida inadvertidamente quando o OpenSSH 8.5p1 foi lançado em outubro de 2020 – o que significa que a vulnerabilidade reexistiu silenciosamente por quase quatro anos antes da descoberta.

Versões afetadas

requisito glibc: O Qualys PoC explorou a implementação malloc da glibc. O sshd do OpenBSD não é vulnerável. Alpine Linux (que usa musl libc) e macOS não são vulneráveis ​​à técnica de exploração demonstrada, embora a condição de corrida ainda exista.

A condição de corrida explicada

Os manipuladores de sinal em programas C devem chamar apenas funções "async-signal-safe" - um pequeno subconjunto de funções libc que são seguras para chamar de dentro de um manipulador de sinal porque não usam estado compartilhado. O syslog() função é não async-signal-safe porque usa malloc internamente.

# The problematic code path (simplified):
# When LoginGraceTime expires:
SIGALRM → grace_alarm_handler() → syslog() → malloc() internally
                                              ↕ RACE
           main sshd thread also calls        malloc() / free()

# If both malloc operations interleave:
# → Heap corruption
# → With enough attempts: controlled heap layout
# → Remote code execution as root

A exploração requer vencer a condição de corrida de forma confiável, o que requer milhares de tentativas de conexão em minutos. Isso torna a exploração automatizada em escala da Internet um pouco mais lenta do que as típicas vulnerabilidades do tipo “disparar e esquecer” – mas atores sofisticados com acesso persistente a um alvo têm muito tempo.

Dificuldade de exploração

Qualys demonstrou exploração confiável em sistemas de 32 bits (x86). Em sistemas de 64 bits, o ASLR aumenta significativamente a dificuldade. Os pesquisadores observam que com ~10,000 tentativas durante 6-8 horas, a exploração é teoricamente alcançável em sistemas de 64 bits, mas eles não publicaram um PoC funcional para x86_64.

No entanto, a barra pode ser reduzida por:

• Vazamentos de informações que derrotam ASLR (exploits combinados)
• Força bruta em ambientes onde fail2ban ou limitação de taxa não estão configurados
• Pesquisas futuras melhorando a técnica de exploração
• Acesso a sistemas vulneráveis de 32 bits (ainda comuns em IoT e Linux incorporados)

Detecção

# Check OpenSSH version
ssh -V
sshd -V

# Check installed package version (Debian/Ubuntu)
dpkg -l openssh-server | grep openssh

# Check installed package version (RHEL/CentOS)
rpm -qa | grep openssh-server

# Check for brute-force attempts indicative of regreSSHion exploitation
# (very high connection rate from single IP, all failing within grace period)
grep "Connection closed by" /var/log/auth.log | 
  awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# Check for failed logins at high rate
grep "Failed\|Invalid" /var/log/auth.log | 
  awk '{print $11}' | sort | uniq -c | sort -rn | head -10

Mitigação

1. Atualize OpenSSH para 9.8p1+: Todas as principais distribuições lançaram patches poucos dias após a divulgação. apt update && apt upgrade openssh-server ou equivalente.
2. Configure LoginGraceTime como 0: Contexto LoginGraceTime 0 em /etc/ssh/sshd_config impede que o manipulador SIGALRM seja chamado, eliminando a condição de corrida (embora remova o tempo limite de tolerância):

   echo "LoginGraceTime 0" >> /etc/ssh/sshd_config
   systemctl reload sshd

3. Limite de taxa de conexões SSH: Configure a limitação de taxa fail2ban ou iptables para evitar as milhares de conexões necessárias para exploração
4. Restrinja o acesso SSH por IP: Limite o sshd a intervalos de IP de gerenciamento conhecidos usando AllowUsers, ListenAddressou regras de firewall
5. Use apenas chaves SSH: Desative a autenticação por senha – a autenticação baseada em chave adiciona um forte filtro de pré-autenticação
6. Considere mover SSH para uma porta não padrão: Reduz o ruído oportunista do scanner, embora não seja um controle de segurança

Capacidade de detecção KENSAI

• Varredura de banners SSH: KENSAI identifica versões OpenSSH em todos os ativos voltados para a Internet, sinalizando 8.5p1–9.7p1 como vulnerável a CVE-2024-6387
• Verificação de rede interna: Descoberta abrangente de servidores SSH vulneráveis ​​em redes internas
• Auditoria de configuração: Verifica configurações de mitigação (LoginGraceTime, AllowUsers, autenticação somente de chave)
• Validação de patches: Confirma a aplicação do patch após a correção
• Contexto de exposição: Prioriza servidores SSH expostos à Internet em vez de sistemas somente internos