Vários problemas de segurança encontrados no GNU Screen

 (openwall.com)
2 pontos por GN⁺ 2025-05-14 | 1 comentários | Compartilhar no WhatsApp
  • Vulnerabilidades de segurança graves foram encontradas no GNU Screen 5.0.0 e em instalações com setuid-root
  • Os principais problemas incluem elevação local para root, sequestro de TTY e criação de PTY gravável por todos
  • Várias distribuições Linux e UNIX são afetadas parcial ou totalmente
  • Há patches temporários disponíveis e muitas distribuições precisam priorizar correções
  • O próprio design do Screen com setuid-root apresenta riscos de segurança fundamentais

1. Introdução

  • Em julho de 2024, a revisão de segurança começou quando o mantenedor upstream do Screen solicitou uma revisão de código
  • Antes, nenhum problema relevante havia sido encontrado, mas desta vez foi descoberta uma vulnerabilidade grave de elevação para root no Screen 5.0.0 quando configurado com setuid-root
  • Além disso, foram confirmadas várias vulnerabilidades de menor gravidade que também afetam versões anteriores (como 4.9.1)
  • O relatório inclui conjuntos de patches por versão (4.9.1, 5.0.0)
  • Também inclui configurações e versões do Screen por distribuição, principais vulnerabilidades, riscos de desenvolvimento relacionados a setuid-root, recomendações de reforço de segurança, problemas no processo de divulgação coordenada e matriz de impacto

2. Visão geral da configuração e das versões do Screen

  • Em agosto de 2024, o Screen 5.0.0 foi lançado e passou a ser distribuído no Arch Linux, Fedora 42 e NetBSD 10.1
  • A versão 5.0.0 inclui muitas refatorações, algumas em código existente há mais de 10 anos
  • Algumas vulnerabilidades foram introduzidas no 5.0.0, enquanto outras já existiam em versões anteriores (como 4.9.1)
  • A maioria das distribuições ainda usa a versão 4.9.1
  • O modo multiusuário do Screen só pode ser usado quando instalado com setuid-root, e a complexidade do código aumenta bastante a superfície de ataque
  • Entre as principais distribuições, Arch Linux, FreeBSD e NetBSD instalam o Screen com setuid-root; no Gentoo, isso só é possível com a flag USE “multiuser”

3. Detalhes dos problemas de segurança

3.a) Obtenção local de root via logfile_reopen() (CVE-2025-23395)

  • Ao executar o Screen 5.0.0 com setuid-root, a função logfile_reopen() cria arquivos a partir de caminhos controlados pelo usuário sem abandonar privilégios
  • Um invasor pode criar arquivos arbitrários pertencentes a root para registrar e explorar dados do terminal
  • Arquivos já existentes também podem ser explorados, por exemplo com injeção de código em shell scripts privilegiados
  • Arch Linux e NetBSD 5.0.0 são totalmente vulneráveis; Fedora e certos ambientes no Gentoo são parcialmente vulneráveis
  • O patch foi aplicado restaurando o tratamento seguro de arquivos, com impacto específico variando por distribuição

3.b) Sequestro de TTY ao conectar-se a sessões multiusuário (CVE-2025-46802)

  • Na função Attach(), quando a flag multiattach está ativada, as permissões do TTY são temporariamente alteradas para 0666
  • Nesse processo, uma condição de corrida (race condition) pode permitir que um terceiro usuário leia e escreva nesse TTY
  • Há risco de espionagem de entrada, manipulação de dados e roubo de senhas
  • Também existem caminhos de código em que as permissões do TTY não são restauradas ao estado original
  • O patch remove a alteração para chmod 666; alguns casos de reconexão podem deixar de funcionar, mas eles já não funcionavam corretamente antes

3.c) Permissões padrão inseguras de PTY (CVE-2025-46803)

  • No 5.0.0, as permissões padrão de PTY foram alteradas de 0620 para 0622 (gravável por todos)
  • Isso aumenta o risco potencial de segurança, especialmente porque qualquer usuário passa a poder escrever em outros PTYs
  • Essa mudança parece ter sido introduzida por engano, e o patch corrige isso restaurando o padrão seguro (0620) na compilação
  • Arch Linux e NetBSD são os principais afetados

3.d) Vazamento de informação sobre existência de arquivos por mensagens de erro de socket (CVE-2025-46804)

  • Usando a variável de ambiente SCREENDIR e mensagens de erro, é possível verificar com privilégios de root a existência real de arquivos/diretórios
  • Trata-se de um vazamento menor de informação, mas o risco existe em todos os ambientes instalados com setuid-root

3.e) Condição de corrida TOCTOU no envio de sinais (CVE-2025-46805)

  • Devido à diferença de tempo entre as funções CheckPid() e Kill(), há risco de sinais serem enviados com privilégios de root a um PID diferente do pretendido
  • Como em geral apenas sinais como SIGCONT e SIGHUP são permitidos, o impacto é limitado, mas ainda pode causar negação de serviço (DoS) ou leve comprometimento de integridade

3.f) Overflow ao enviar comandos por uso incorreto de strncpy()

  • No 5.0.0, o uso incorreto de strncpy() causa buffer overflow e travamento do programa
  • Se não for corrigido adequadamente, o envio de comandos pode sobrescrever memória após MAXPATHLEN e levar a indisponibilidade do serviço
  • Não é um problema de segurança, mas exige correção rápida por motivos de estabilidade

4. Riscos adicionais relacionados à implementação com setuid-root

  • Foi confirmada uma lógica fraca no tratamento de UIDs de múltiplos usuários no modo multiusuário
  • A lógica de redução de privilégios no estado setuid-root não é completa
  • Em sessões criadas por root, a redução efetiva de privilégios não acontece corretamente, elevando o risco geral

5. Recomendações gerais de reforço de segurança

  • Durante a grande refatoração do código, foi constatada a quebra de lógicas de segurança existentes
  • Por se tratar de um binário setuid-root, é necessário introduzir uma suíte de testes de segurança e projetar de forma conservadora todo o tratamento de sistema de arquivos e variáveis de ambiente
  • Em especial, a execução integral com setuid-root não é recomendada, e o recurso multiusuário deve ser limitado apenas a grupos confiáveis por opt-in
  • Variáveis de ambiente (como PAH) devem ser obrigatoriamente restringidas a caminhos confiáveis

6. Problemas no processo de coordenação da divulgação das vulnerabilidades

  • O processo de coordenação com o upstream foi ineficiente, causando atrasos no desenvolvimento dos patches e na divulgação
  • Foi difícil obter uma resposta próxima devido à falta de entendimento do código e de capacidade técnica do upstream
  • No fim, o lado das distribuições liderou o desenvolvimento dos patches, e a publicação do relatório seguiu o cronograma coordenado
  • Também ficou evidente a falta de capacidade de manutenção e gestão do próprio projeto Screen

7. Matriz de impacto

  • Arch Linux (5.0.0, setuid-root): afetado por todas as vulnerabilidades 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
  • Debian/Ubuntu e várias outras distribuições: 3.b (impacto parcial)
  • Fedora 42 (5.0.0, setgid-screen): afetado por 3.b (impacto parcial) e 3.f
  • Gentoo (4.9.1, setgid-utmp): afetado por 3.b (impacto parcial); com ebuild unstable + flag USE multiuser, tem o mesmo impacto do 5.0.0
  • FreeBSD 14.2 (4.9.1, setuid-root): afetado por 3.b, 3.d, 3.e
  • NetBSD 10.1 (5.0.0, setuid-root): afetado por 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
  • OpenBSD 7.7 (4.9.1): 3.b (impacto parcial)
  • openSUSE TW: 3.b (impacto parcial)

8. Cronograma

  • 2024-07-01: recebida solicitação de revisão de código do upstream
  • 2025-01-08: início da revisão
  • 2025-02-07: vulnerabilidades reportadas em privado ao upstream, com pedido de divulgação coordenada
  • 2025-02~04: discussões sobre patches em andamento, com replanejamento devido a questões no período de embargo
  • 2025-05-12: publicação deste relatório e anúncio oficial

9. Links de referência

  • GNU Savannah [página do projeto Screen]
  • openSUSE Bugzilla, patches relacionados, CVEs de referência, relatórios de bug e links de documentação incluídos

Leituras relacionadas

1 comentários

 
GN⁺ 2025-05-14
Comentários do Hacker News
  • O Screen tem um modo multiusuário que permite que vários usuários se conectem à mesma sessão ao mesmo tempo; acho que é esse recurso que torna possíveis ferramentas como o tmate, e fico curioso se o tmux tem a mesma vulnerabilidade
    • O tmux usa sockets de domínio Unix; não entendo por que o screen adotou a abordagem setuid, já que não parece precisar de privilégios de root; pelo que foi explicado no TFA, aparentemente os desenvolvedores atuais do screen não entendem totalmente a base de código e escolheram setuid-root porque era a forma mais fácil de implementar o recurso
    • Esse recurso é realmente excelente; em sessões de treinamento, eu dava a cada aluno sua própria conta de login no meu notebook e restringia o shell via ssh para screen -x <janela de um usuário específico>, de modo que o aluno só pudesse usar as janelas permitidas pelo ACL daquele screen; eu então usava um projetor para mostrar e verificar a tela de cada aluno, um por um; ainda assim, não surpreende que isso esteja cheio de brechas de segurança
    • Já usei o comando screen -x
  • No Debian, o GNU screen não é instalado com privilégios setuid root
    • O pacote do Debian Stable (bookworm) é antigo demais para ser afetado pela vulnerabilidade do 5.0.0; antes eu odiava como o Debian demorava demais para atualizar versões de software, mas hoje uso fontes de pacote separadas só para alguns aplicativos que realmente preciso manter atualizados, e para o resto sigo usando versões antigas sem problemas
    • No Gentoo é a mesma coisa, mas lá o SETGID é configurado para o grupo utmp; não sei bem o que isso significa
    • No Slackware 15, o screen não tem suid
    • No Fedora, parece ser instalado como setuid
  • Apresenta a versão renderizada do post do blog: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Mandei um e-mail ao autor do texto por causa da falta de documentação sobre o recurso de gravação em arquivo de log do GNU Screen; acho que o GNU precisa de um sistema melhor de rastreamento de issues; material relacionado: http://www.zoobab.com/screenrc
  • O comportamento observado já existia no Screen desde 2005, e esse antipadrão vinha sendo coberto por ferramentas como o rkhunter há muito tempo; tenho quase certeza de que o screen já era setuid root nos anos 90
  • Surpreende que o upstream (equipe oficial de desenvolvimento) tenha se envolvido desta vez; fiquei triste há uns 5 anos porque parecia que o desenvolvimento do GNU screen tinha parado completamente; queria saber se isso ainda é verdade, e também se existe um recurso para adicionar novas janelas ao screen sem fazer attach à tela
    • Foi o upstream que pediu revisão à equipe da SUSE; há pouca mão de obra de desenvolvimento e a manutenção atual não parece muito ativa; se for esse o caso, é uma pena; existem alternativas como o tmux, mas muita gente usa o Screen há muito tempo, e é triste ver as ferramentas envelhecerem assim
    • O único envolvimento foi distribuir como setuid-root; só as distribuições configuradas assim são vulneráveis, as demais não são afetadas; quando o patch oficial demora, as distribuições aplicam correções por conta própria
    • Não acho necessariamente ruim quando o desenvolvimento de ferramentas GNU para (exceto correções de bug); isso pode ser um sinal de que o recurso já está suficientemente completo
    • É difícil se comunicar com o upstream, então não há muitas informações detalhadas sobre correções de bugs ou releases; pediram a revisão de segurança, mas parece ser difícil entrar em contato com eles
    • No open source existe o problema da inércia: mesmo quando um software chega ao fim e surge um substituto, muitas vezes não há incentivo suficiente para migrar imediatamente; por outro lado, também há casos em que alguém compra só a marca e transforma tudo em outra coisa completamente diferente (como no caso do Audacity); não existe uma boa solução para isso
  • Link da versão renderizada: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Fico curioso sobre quantos desenvolvedores realmente usam por conta própria todas essas ferramentas populares de open source, e quanto dinheiro circula nas áreas que dependem delas
  • Pelo que me lembro, o tmux passou a vir por padrão no OpenBSD a partir da 4.6 e foi auditado; é uma boa alternativa para quem se preocupa mais com segurança
    • Ver o screen sendo mencionado me trouxe a lembrança de quando migrei para o tmux no passado e depois me confundia por acidentalmente não usar mais o screen
  • É curioso ver screen e setuid mencionados juntos; certa vez, para tentar resolver um problema estranho, dei chmod u+s no screen; parecia esquisito ter que fazer isso, mas depois descobri que o screen tinha recursos que dependiam de setuid e que em alguns sistemas ele já era distribuído assim por padrão; e quando apliquei u+s, o screen passou a ler o ~/.screenrc do root em vez do meu ~/.screenrc (aceitei isso como gambiarra temporária); imagino que o suporte a setuid possa variar conforme a build do screen
    • É assim mesmo que o setuid funciona originalmente: quando você define esse bit especial no binário, isso significa que ele sempre deve ser executado como o usuário fornecido