CVE-2020-14871

Buffer overflow (CWE-787, escrita fora de limites) no módulo PAM do Oracle Solaris, na função de parsing do nome de usuário (parse_user_name), explorável remotamente e sem autenticação via SunSSH e outros serviços que invocam PAM. Atribuída CVSS 10.0 porque permite takeover completo do sistema sem nenhuma pré-condição de acesso, mas a própria Oracle nota que a falha não existe mais a partir do Solaris 11.1 — ou seja, o CVSS 10.0 só se aplica a Solaris 10 e a builds antigas de Solaris 11 ainda em suporte estendido. Está no catálogo KEV da CISA e foi usada por um grupo de ameaça (UNC1945, documentado pela Mandiant) contra servidores Solaris com SSH exposto à internet.

A falha está na implementação Sun/Oracle do PAM (Pluggable Authentication Module), especificamente no tratamento do nome de usuário recebido pelo daemon SSH (SunSSH) antes de ser passado para pam_start(). O nome de usuário não tem limite de tamanho sensato imposto antes de entrar na pilha de chamadas do PAM, permitindo que um atacante envie uma string de nome de usuário extremamente longa (relatos de exploits públicos usam strings da ordem de dezenas a ~128KB) que sobrescreve estruturas de memória além do buffer alocado.

O commit de mitigação do OpenSSH portátil (8.5, novembro de 2020) descreve o problema como 'buffer overflow in Solaris' PAM username handling', corrigido no lado do cliente/servidor SSH checando strlen(user) contra PAM_MAX_RESP_SIZE antes de repassar ao PAM, mas apenas quando a implementação de PAM é identificada como 'Sun-derived' (flag PAM_SUN_CODEBASE). Isso confirma que o bug reside no PAM da Oracle, não no OpenSSH — o OpenSSH apenas evita ser um dos vetores de disparo.

Exploits públicos catalogados no Packet Storm nomeiam a função vulnerável como 'parse_user_name' dentro do PAM do SunSSH, com variantes para Solaris 10 x86 e Solaris 11.0 x86/libpam, indicando que a rota de heap overflow (técnicas como 'House of Mind' foram citadas em discussões relacionadas de exploração de PAM em glibc/Solaris) foi adaptada para diferentes versões e arquiteturas.

Por ser um componente PAM, e não exclusivamente o SSH, a Oracle descreve o vetor como 'via multiple protocols' — qualquer serviço de rede em Solaris que autentique via PAM e passe o nome de usuário sem sanitização (login, telnet, ftp, além de sshd) é uma superfície de ataque potencial, embora o exploit documentado publicamente seja via SunSSH.

O vetor documentado e com exploits públicos é o daemon SunSSH do Solaris: o atacante conecta-se ao serviço SSH exposto e envia, no campo de nome de usuário durante a negociação de autenticação, uma string malformada e excessivamente longa. Não é necessária autenticação prévia, nem chave, nem conta válida — o overflow ocorre antes de qualquer verificação de credencial, na fase de parsing do username pelo PAM. Não há interação do usuário nem configuração não padrão exigida: basta o serviço estar acessível na rede.

Existem múltiplos exploits públicos catalogados (Packet Storm) com variantes específicas por versão e arquitetura (Solaris 10 x86, Solaris 11.0 x86 com libpam, Solaris 11.0 genérico), e um módulo Metasploit, o que reduz a complexidade prática de exploração a quase zero para quem tem acesso de rede ao serviço. Sucesso na exploração resulta em execução de código com privilégios do processo que chama o PAM — tipicamente root, já que sshd e serviços de login rodam com privilégios elevados durante a fase de autenticação.

A exploração ativa está confirmada: a Mandiant documentou o grupo UNC1945 comprometendo servidores Solaris com SSH exposto à internet, com dwell time de cerca de 519 dias antes da detecção, instalando um backdoor (SLAPSTICK) para capturar credenciais. A CISA incluiu a CVE no catálogo KEV com prazo de correção em 2022-05-03, confirmando exploração no mundo real, não apenas prova de conceito.

A correção definitiva é migrar para uma versão de Solaris onde a falha não existe: a própria Oracle afirma que Solaris 11.1 e posteriores, e Oracle ZFS Storage Appliance (ZFSSA) 8.7 e posteriores, já não são vulneráveis a esta CVE. Para Solaris 10 e para instalações de Solaris 11 anteriores a 11.1 ainda sob suporte, é necessário aplicar o Critical Patch Update de outubro de 2020 da Oracle (cpuoct2020) — não há número de patch específico detalhado nas fontes consultadas aqui; siga o advisory oficial da Oracle para o identificador exato do patch aplicável à sua versão e arquitetura.

Como paliativo parcial quando o patch da Oracle não pode ser aplicado imediatamente: atualizar para OpenSSH portátil 8.5 ou posterior no lado do cliente/servidor SSH adiciona uma verificação que rejeita nomes de usuário excessivamente longos antes de repassá-los ao PAM, mas essa mitigação só se aplica quando o próprio OpenSSH (não o SunSSH nativo da Oracle) é usado como daemon SSH, e só protege contra o vetor via sshd — não fecha a falha no PAM em si, que continua explorável por qualquer outro serviço PAM (login, ftp, telnet) que aceite nome de usuário de rede.

Controles compensatórios reais quando não é possível corrigir: restringir acesso de rede aos serviços autenticados via PAM (SSH, login, ftp) do Solaris afetado por firewall/ACL, limitando exposição a redes confiáveis; monitorar e limitar o tamanho de campos de autenticação em proxies/gateways na frente do serviço, quando existirem. Não funciona como mitigação: apenas trocar de shell, desabilitar contas específicas, ou confiar em autenticação por chave SSH — o overflow ocorre antes da verificação de credencial, então nenhuma configuração de conta impede o ataque.

Em nível de rede/aplicação, procure tentativas de autenticação SSH (ou outros serviços PAM: login, ftp, telnet) com campos de nome de usuário anormalmente longos — muito além do que qualquer conta legítima teria (exploits documentados usam desde poucos KB até ~128KB). Logs do sshd ou do PAM que mostrem falhas de autenticação truncadas, crashes do processo de autenticação, ou reinícios inesperados do daemon sshd/pam em hosts Solaris são indícios fortes de tentativa de exploração.

Não há assinatura única confiável para todas as variantes, já que existem múltiplos exploits públicos com técnicas e tamanhos de payload diferentes por versão/arquitetura; ambientes que já sofreram comprometimento real (caso UNC1945) foram detectados por indicadores de pós-exploração — backdoors, credenciais capturadas, atividade lateral — e não pela assinatura do exploit em si, o que reforça a importância de monitorar comportamento pós-autenticação em hosts Solaris expostos à internet, não apenas o tráfego de exploração.