CVE-2019-3010

Falha de design no XScreenSaver distribuído com o Oracle Solaris 11.x que permite a um atacante local com login válido (baixo privilégio) escalar para root ou causar negação de serviço, abusando do parâmetro de linha de comando -log. O CVSS de 8.8 é coerente com o risco real: não há elevação remota, mas qualquer usuário autenticado no host pode assumir controle total do sistema com esforço mínimo. Está no catálogo KEV da CISA, tem PoC pública e módulo Metasploit — é uma escalada de privilégio local, não uma RCE remota, mas trivial de explorar onde há múltiplos usuários com shell.

O problema está no parâmetro -log, introduzido na versão 5.06 do XScreenSaver upstream e presente no binário empacotado pela Oracle no Solaris 11.x. Segundo a análise de Marco Ivaldi (pesquisador conhecido como Raptor), o tratamento desse parâmetro contém um erro de design (CWE-269, Improper Privilege Management, combinado com controle inadequado de caminho de arquivo — CWE-73) que permite ao usuário especificar um caminho de arquivo de log arbitrário no sistema.

O binário roda com privilégios elevados no contexto de tela de bloqueio do Solaris, e a rotina de logging não valida corretamente permissões, propriedade ou existência prévia do arquivo alvo antes de criar ou anexar conteúdo. Isso permite ao atacante local direcionar a escrita para arquivos fora de seu diretório home — inclusive arquivos de configuração sensíveis do sistema — sem que o binário verifique se ele já tem direito legítimo de escrita ali.

O atacante controla o caminho de destino (via -log) e, em certa medida, o conteúdo que acaba sendo escrito ou anexado ao arquivo. Isso é suficiente tanto para corromper arquivos críticos (negação de serviço) quanto, dependendo do arquivo escolhido, para inserir dados que levam à execução com privilégios de root — por isso o Scope Changed (S:C) no vetor CVSS: o impacto extravasa o componente vulnerável para o sistema operacional inteiro.

Pré-requisito real: acesso de login local ao host Solaris — qualquer conta de usuário comum serve, não precisa ser privilegiada (PR:L no vetor). Não há interação de usuário adicional necessária (UI:N) e a complexidade de ataque é baixa (AC:L), o que explica o score alto mesmo sendo estritamente local.

O fluxo de exploração publicado por Ivaldi consiste em invocar o xscreensaver com o switch -log apontando para um arquivo escolhido pelo atacante, forçando a criação ou o append de conteúdo em local que o usuário não deveria poder escrever. A PoC e o exploit completo estão publicados (repositório do próprio pesquisador e PacketStorm), o que tornou a exploração trivial de reproduzir e provavelmente motivou a inclusão no catálogo KEV da CISA em maio de 2022, com prazo de correção fixado para 15/06/2022 para agências federais dos EUA — evidência de exploração ativa observada, embora a CISA não classifique como associada a campanhas de ransomware conhecidas.

O resultado final documentado é escalonamento de privilégios para root ou negação de serviço via corrupção de arquivo. Não se trata de execução remota: o atacante já precisa estar dentro do perímetro com uma sessão de shell.

A correção oficial veio na Critical Patch Update (CPU) de outubro de 2019 da Oracle para Solaris 11, identificada como CPUoct2019 (advisory cpuoct2019-5072832). Aplicar essa CPU (ou qualquer CPU posterior que a inclua) é a mitigação definitiva; os números exatos de patch/pacote para cada release do Solaris 11 devem ser confirmados no advisory oficial da Oracle, pois não foram detalhados nas fontes disponíveis aqui.

Como controle compensatório quando a atualização não é imediata, o custo-benefício está em restringir ou remover a capacidade de usuários locais não confiáveis de invocar o xscreensaver com privilégios elevados — isso pode envolver revisão de permissões do binário e de qualquer componente PAM/setuid associado ao bloqueio de tela, mas nenhuma configuração específica de flag ou parâmetro alternativo foi documentada nas fontes consultadas, então não há um workaround granular confirmado além de restringir quem tem shell local no host.

O que não funciona como mitigação: como é uma falha estritamente local, controles de rede (firewall, WAF, segmentação) não reduzem o risco — o vetor de ataque é AV:L, então a única superfície relevante é quem tem conta e acesso a shell no Solaris afetado.

Em ambientes com auditoria BSM habilitada no Solaris, procurar invocações do binário xscreensaver com o parâmetro -log apontando para caminhos fora do diretório home do usuário ou para arquivos de propriedade de root/sistema. Correlacionar criação ou modificação inesperada de arquivos de sistema (timestamps) com sessões de login local ativas no mesmo período é o sinal mais confiável disponível, já que não há assinatura de rede — o ataque é inteiramente local e não deixa rastro em tráfego.