RegreSSHion: execução remota de código (RCE) no servidor OpenSSH em sistemas Linux baseados em glibc

Resumo

• Descoberta de vulnerabilidade de segurança no OpenSSH: Foi descoberta uma vulnerabilidade de execução remota de código (RCE) no servidor OpenSSH (sshd) causada por uma condição de corrida no manipulador de sinais. Essa vulnerabilidade afeta o sshd na configuração padrão.
• Origem da vulnerabilidade: Essa vulnerabilidade é uma regressão do CVE-2006-5051, relatado em 2006, e ocorreu devido a uma alteração de código introduzida no OpenSSH 8.5p1 em outubro de 2020.
• Impacto da vulnerabilidade: Pode ser explorada remotamente em sistemas Linux baseados em glibc e afeta o código privilegiado do sshd, permitindo execução remota de código com privilégios de root.
• Como a vulnerabilidade é explorada: Para explorar essa vulnerabilidade, é necessário encontrar um caminho de código específico e interrompê-lo no momento certo. Para isso, o estudo começou em versões antigas do OpenSSH e foi expandido até as versões mais recentes.
• Patch e mitigação: São fornecidos patch e métodos de mitigação para corrigir a vulnerabilidade.

SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, 2005)

Teoria

• Manipulador SIGALRM: O manipulador de SIGALRM nessa versão chama packet_close(), que chama buffer_free(), que por sua vez chama xfree() e free(). free() não é async-signal-safe.
• Análise do código de malloc: Ao analisar o código de malloc, foi encontrado um caminho para explorar a vulnerabilidade quando uma chamada a free() é interrompida por SIGALRM e chamada novamente dentro do manipulador de SIGALRM.

Prática

• Método de ataque: A execução remota de código foi alcançada interrompendo uma chamada a free() no código que faz o parsing de uma chave pública DSA e explorando isso dentro do manipulador de SIGALRM.
• Vencer a condição de corrida: Para vencer essa condição de corrida, são necessárias cerca de 10.000 tentativas, levando em média cerca de uma semana.

Timing

• Estratégia de timing: Para minimizar a latência de rede, o último byte é enviado no último instante, e o tempo de ida e volta é monitorado para ajustar o timing. Com isso, aumenta-se a probabilidade de vencer a condição de corrida.

SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, 2006)

Teoria 1

• Manipulador SIGALRM: O manipulador de SIGALRM nessa versão não chama packet_close(), e como a função malloc sempre aplica bloqueio, foi necessária outra solução.
• Uso de PAM: Foi descoberto que pam_end() do PAM não é async-signal-safe, e foi explorado um caminho para abusar disso.

Teoria 2

• Análise de pam_start(): Se pam_start() for interrompido, a estrutura PAM pode permanecer em um estado inconsistente, o que pode ser explorado dentro do manipulador de SIGALRM.
• Técnica House of Mind: Para o ataque, foi usada a técnica House of Mind para manipular a alocação de memória e alcançar execução remota de código com privilégios de root.

Prática

• Método de ataque: A alocação de memória é manipulada com nomes de usuário longos, e a probabilidade de vencer a condição de corrida é aumentada por meio de várias chamadas a pam_start().

Timing

• Estratégia de timing: A estratégia de timing usada na versão anterior do Debian foi reutilizada para aumentar a probabilidade de vencer a condição de corrida. Em média, isso leva de 1 a 2 dias.

SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 (Debian 12.5.0, 2024)

Teoria

• Manipulador SIGALRM: O manipulador de SIGALRM nessa versão chama syslog(), que por sua vez chama funções que não são async-signal-safe.
• Análise da glibc: O syslog() da glibc chama malloc, que não é async-signal-safe. Além disso, a função malloc da glibc não aplica bloqueio quando está em thread única.

Patch e mitigação

• Patch: A vulnerabilidade foi reportada aos desenvolvedores do OpenSSH, e foi fornecido um patch para corrigir o problema.

Opinião do GN⁺

• Importância da segurança: O OpenSSH é um software de segurança extremamente importante, e essa vulnerabilidade é um caso muito raro.
• Dificuldade de exploração da vulnerabilidade: Explorar essa vulnerabilidade exige timing extremamente preciso e muitas tentativas.
• Soluções alternativas: Além do OpenSSH, existem várias soluções de segurança, e é recomendável usá-las em conjunto.
• Desafio técnico: Esta pesquisa exige um nível técnico muito alto e pode servir de grande inspiração para pesquisadores de segurança.
• Mitigação da vulnerabilidade: É importante aplicar os patches de segurança mais recentes e reforçar as configurações de segurança.

[GN⁺]

Comentários do Hacker News

• A correção do RCE foi publicada de forma quase "discreta" há quase um mês

  • Quando PerSourcePenalties está ativado, o sshd(8) monitora o estado de encerramento dos processos filhos de sessão de pré-autenticação
  • Registra penalidades quando um cliente tenta se autenticar repetidamente ou quando o sshd falha
  • Esse patch altera a arquitetura do binário para remover uma vulnerabilidade específica e mitigar toda uma classe de exploits

• No diff que introduziu o bug, a função foi refatorada da seguinte forma

  • Função original: sigdie(const char *fmt,...)
  • Função refatorada: sshsigdie(const char *file, const char *func, int line, const char *fmt, ...)
  • Faltou um #ifdef
  • Isso poderia ter sido evitado se mais pessoas tivessem revisado o pull request

• Comentário interessante nas notas de lançamento do OpenSSH

  • Um exploit bem-sucedido foi demonstrado em sistemas Linux/glibc de 32 bits com ASLR
  • Parece provável que também seja possível em sistemas de 64 bits

• O OpenBSD não é afetado por essa vulnerabilidade porque o handler de SIGALRM chama syslog_r()

  • Usa uma versão async-signal-safe de syslog()
  • Foi necessária uma refatoração para minimizar a quantidade de código dentro do signal handler

• Ao analisar o syslog(3) do musl, viu-se que ele não é facilmente explorável, ao contrário do glibc

  • Tudo fica na stack ou em variáveis estáticas protegidas contra reentrada

• Foi lançado um patch para FreeBSD e, como ele não usa glibc, é provável que não seja afetado

• Definir LoginGraceTime 0 no arquivo sshd_config pode mitigar o problema

  • Isso o torna vulnerável a ataques de negação de serviço, mas impede a execução remota de código

• Foi lançado um patch para Debian 12, e o Debian 11 não é afetado

• Foram fornecidos links para as notas de lançamento do OpenSSH e para o patch mínimo

• De um ponto de vista independente, encontrar uma única vulnerabilidade já deveria ser suficiente

  • Há uma tendência de as pessoas só levarem a sério ou pagarem recompensas quando toda a cadeia é encontrada