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

• Uma revisão de segurança do GNU Screen confirmou, com foco no Screen 5.0.0 e em instalações setuid-root, escalonamento local de privilégios, sequestro de TTY, vazamento de informações, condição de corrida no envio de sinais e crash no envio de comandos
• O mais grave, CVE-2025-23395, permite que logfile_reopen() trate caminhos fornecidos pelo usuário com privilégios de root, possibilitando criar arquivos pertencentes ao root em locais arbitrários ou anexar logs a arquivos existentes
• O comportamento antigo do modo multiusuário também se mostrou problemático: Attach() muda temporariamente o TTY para 0666, abrindo possibilidade de leitura, escrita e injeção de entrada por outros usuários
• O risco varia conforme a forma de instalação em cada distribuição; Arch Linux e NetBSD 10.1 fornecem o Screen 5.0.0 como setuid-root e sofrem fortemente o impacto das principais vulnerabilidades
• A recomendação atual é não instalar o Screen como setuid-root; o recurso multiusuário precisa de opt-in baseado em grupos confiáveis, redução de privilégios por padrão, elevação limitada de privilégios e limpeza de variáveis de ambiente

---

Contexto da divulgação e patches

• Em julho de 2024, o mantenedor upstream do Screen pediu uma revisão da base de código atual, e a revisão de segurança de fato começou em janeiro de 2025
• O resultado da revisão identificou um exploit local para root que afeta distribuições que empacotam o Screen 5.0.0 com setuid-root
• Também foram confirmados problemas adicionais de menor gravidade, alguns deles afetando ainda o Screen 4.9.1 e versões anteriores presentes em várias distribuições
• Os problemas foram compartilhados na mailing list distros em 30 de abril de 2025 e divulgados publicamente em 12 de maio de 2025
• O relatório inclui conjuntos de patches por versão
  • screen-4.9.1-patches.tar.gz
  • screen-5.0.0-patches.tar.gz

Configuração do Screen e modo multiusuário

• O Screen 5.0.0 foi lançado upstream em agosto de 2024 como uma versão importante, e Arch Linux, Fedora 42 e NetBSD 10.1 oferecem essa versão
• Muitas distribuições Linux e UNIX ainda usam Screen 4.9.1 no momento da redação
• O modo multiusuário do Screen permite anexar-se a sessões do Screen pertencentes a outros usuários quando há credenciais adequadas
  • Esse recurso só pode ser usado quando o Screen é instalado com o bit setuid-root
  • Como código complexo do Screen roda com privilégios de root, a superfície de ataque aumenta
• Entre os sistemas revisados, Arch Linux, FreeBSD e NetBSD instalam o Screen como setuid-root
• No Gentoo Linux, o bit setuid-root é aplicado quando a flag USE "multiuser" está ativada
• Algumas distribuições usam setgid em vez de setuid
  • O padrão do Gentoo Linux é setgid-utmp, permitindo que o Screen crie registros de login no banco de dados global utmp
  • O Fedora Linux usa setgid-screen, permitindo que o Screen coloque sockets no diretório global /run/screen

CVE-2025-23395: exploit local para root em logfile_reopen()

• CVE-2025-23395 afeta o Screen 5.0.0 quando executado com privilégios setuid-root
• A função logfile_reopen() não reduz privilégios ao processar um caminho fornecido pelo usuário
• Um usuário sem privilégios pode criar arquivos em locais arbitrários com as seguintes características
  • proprietário: root
  • grupo: grupo real do usuário que invocou o processo
  • modo do arquivo: 0644
• Arquivos já existentes também podem ser explorados
  • Dados gravados no PTY do Screen são anexados a esse arquivo
  • O modo e a propriedade do arquivo existente não são alterados
• O Screen reduz privilégios corretamente ao abrir o arquivo de log pela primeira vez, mas a possibilidade de elevação aparece quando decide que precisa reabri-lo
• A checagem stolen_logfile() chama logfile_reopen() quando o link count do arquivo de log original vira 0 ou quando seu tamanho muda de forma inesperada
• Um usuário sem privilégios pode provocar essa condição de propósito
• O patch 0001 para o Screen 5.0.0 reintroduz tratamento seguro de arquivos no processo de reabertura do log
• O problema surgiu quando lf_secreopen() foi removida no commit antigo 441bca708bd, mudança que acabou entrando no release 5.0.0

CVE-2025-46802: sequestro de TTY durante attach de sessão multiusuário

• CVE-2025-46802 ocorre na função Attach() quando a flag multiattach está definida
• Ao anexar-se a uma sessão multiusuário, o Screen altera com chmod() o modo do TTY atual para 0666
• Como o caminho do TTY é validado com verificações como estar sob /dev e satisfazer isatty(), esse comportamento por si só não vira um exploit local para root separado
• O problema é que, enquanto as permissões do TTY ficam temporariamente relaxadas, surge uma condição de corrida em que outros usuários podem ler e escrever nesse TTY
• Em um teste simples baseado na API Linux inotify, um script Python conseguiu abrir o TTY afetado a cada duas ou três tentativas
• Um atacante pode fazer o seguinte
  • interceptar dados digitados no TTY
  • injetar dados no TTY
  • induzir o usuário a digitar uma senha
  • injetar sequências de controle para confundir a vítima ou explorar problemas relacionados no emulador de terminal
• Em alguns caminhos de retorno de Attach(), o modo original do TTY não é restaurado
  • Exemplo: quando a sessão de destino não é encontrada e o argumento "quiet" está definido
• O patch remove o chmod() temporário
  • patch 0001 para o Screen 4.9.1
  • patch 0004 para o Screen 5.0.0
• Pouco antes da divulgação, identificou-se que esse patch poderia quebrar alguns casos de uso de reattach, mas verificou-se que esses casos já estavam quebrados no Screen 4.9.1
• O problema existe em versões do Screen desde pelo menos 2005 e afeta distribuições Linux e BSD que oferecem suporte multiusuário com setuid-root
• Mesmo sem setuid-root, em teoria pode haver impacto porque o usuário tem permissão para mudar o modo do próprio TTY, mas o Screen não prossegue em sessões de outros usuários sem privilégios de root

CVE-2025-46803: padrão de PTY gravável por todos no Screen 5.0.0

• CVE-2025-46803 trata da mudança do modo padrão dos PTYs alocados pelo Screen no 5.0.0, de 0620 para 0622
• Com esse padrão, qualquer usuário do sistema pode escrever no PTY do Screen
• Em termos de segurança, isso cria um problema semelhante ao CVE-2025-46802, mas sem o aspecto de vazamento de informações
• No Screen 4.9.1, o padrão no nível do código era 0622, mas o padrão 0620 da configuração autotools prevalecia e resultava em um padrão seguro
• No Screen 5.0.0, a reescrita de configure.ac removeu o padrão 0620 do nível autoconf, e depois a opção de configuração pty-mode foi reintroduzida com padrão 0622
• As notas de release do 5.0.0 não foram encontradas e havia apenas alguns itens no ChangeLog, então a mudança do padrão do modo PTY não parece ter sido uma decisão intencional
• O patch 0002 para o Screen 5.0.0 restaura em configure.ac um modo PTY padrão seguro
  • Para aplicar a mudança, é necessário executar autoreconf
• Recomenda-se aos empacotadores passar explicitamente a opção --with-pty-mode=0620 ao configure
• Gentoo Linux e Fedora Linux passam explicitamente uma opção --with-pty-mode segura
• Arch Linux e NetBSD não passam essa opção, então o novo padrão é aplicado e eles ficam vulneráveis

CVE-2025-46804: divulgação da existência de arquivos por mensagens de erro no caminho de socket

• CVE-2025-46804 é um vazamento leve de informações que ocorre quando o Screen roda com privilégios setuid-root
• Foi confirmado tanto em versões antigas do Screen quanto no 5.0.0
• O Screen verifica SocketPath com privilégios de root e expõe em mensagens de erro informações de caminho que um usuário sem privilégios normalmente não conheceria
• Usando a variável de ambiente SCREENDIR, é possível inferir as seguintes informações
  • se /root/.lesshst é um arquivo comum
  • se o diretório /root/.cache existe
  • se o caminho /root/test não existe
• O patch passa a mostrar apenas mensagens de erro genéricas em instalações setuid-root quando o caminho de destino não é controlado pelo UID real do processo
  • patch 0002 para o Screen 4.9.1
  • patch 0005 para o Screen 5.0.0
• Todas as distribuições revisadas são afetadas

CVE-2025-46805: condição de corrida TOCTOU no envio de sinais

• CVE-2025-46805 é uma condição de corrida TOCTOU ao enviar sinais para um PID fornecido pelo usuário em contexto setuid-root
• CheckPid() reduz privilégios para o ID real do usuário antes de verificar se o kernel permite enviar um sinal ao PID de destino
• O sinal real é enviado depois por Kill(), momento em que privilégios de root podem ser usados
• Entre a checagem e o envio real, o PID verificado anteriormente pode ser substituído por outro processo privilegiado
• Também pode ser possível induzir um processo daemon privilegiado do Screen a enviar um sinal para si mesmo
• No momento, só é possível enviar SIGCONT e SIGHUP, então o impacto tende a ficar no campo de negação local de serviço ou violação leve de integridade
• O problema deriva de uma correção incompleta do CVE-2023-24626
  • Antes dessa correção, era possível enviar esses sinais a processos arbitrários mesmo sem a condição de corrida
• O patch muda o envio real do sinal para usar privilégios do UID real, assim como CheckPid()
  • patch 0003 para o Screen 4.9.1
  • patch 0006 para o Screen 5.0.0
• Todas as distribuições revisadas são afetadas

Crash no envio de comandos causado por uso de strncpy() no Screen 5.0.0

• O Screen 5.0.0 tem um problema relacionado a strncpy() que não é tratado como falha de segurança, mas deve ser corrigido com prioridade
• No commit 0dc67256, várias chamadas a strcpy() foram substituídas por strncpy()
• strncpy() não é uma função para tratamento seguro de strings; ela serve para preencher com 0 um buffer de tamanho fixo e, por isso, escreve 0 até o fim do buffer de destino mesmo após o primeiro byte \0
• No loop de processamento de argumentos de linha de comando em attacher.c, o tamanho de destino MAXPATHLEN continua sendo passado mesmo depois da primeira iteração
• Como o ponteiro p já foi incrementado, as chamadas posteriores a strncpy() escrevem bytes \0 além do fim do buffer
• No Arch Linux, ao enviar dois ou mais argumentos de comando para uma sessão Screen em execução, foi observado o seguinte erro em builds com _FORTIFY_SOURCE habilitado
  • *** buffer overflow detected***: terminated
  • Aborted (core dumped)
• Sem _FORTIFY_SOURCE, pode não haver erro visível, e mesmo com -fsanitize=address o problema pode não aparecer
• O chamador pode sobrescrever com 0 os MAXPATHLEN bytes após o buffer cmd, mas como em seguida existe o buffer writeback[MAXPATHLEN] do mesmo tamanho, considera-se improvável que isso possa ser explorado de forma vantajosa para um atacante
• O patch 0003 para o Screen 5.0.0 troca strncpy() por snprintf() e passa corretamente o tamanho restante do buffer de destino
• Todas as distribuições que fornecem o Screen 5.0.0 são afetadas

Impacto por distribuição

Sistema	Versão do Screen	Privilégio especial	Impacto
Arch Linux	5.0.0	setuid-root	3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10	4.9.0	nenhum	3.b parcial
Ubuntu 24.04.2	4.9.1	nenhum	3.b parcial
Fedora 42	5.0.0	setgid-screen	3.b parcial, 3.f
Gentoo	4.9.1	setgid-utmp, setuid-root quando a flag USE multiuser está ativada	3.b parcial
openSUSE TW	4.9.1	nenhum	3.b parcial
FreeBSD 14.2	4.9.1	setuid-root	3.b, 3.d, 3.e
NetBSD 10.1	5.0.0	setuid-root	3.a, 3.b, 3.c, 3.d, 3.e, 3.f
OpenBSD 7.7	4.9.1	nenhum	3.b parcial

Preocupações e recomendações sobre o design setuid-root

• O modo multiusuário do Screen envolve três UIDs
  • UID efetivo 0 para operações privilegiadas
  • UID real do usuário que criou a sessão
  • UID real do usuário que se anexa à sessão
• O código atual do Screen parece ter uma estrutura que dificulta refletir corretamente essa distinção
• Uma sessão multiusuário do Screen criada por root faz a “redução de privilégios” para o UID real 0 do criador da sessão, então na prática não há redução de privilégios
• Durante a refatoração do Screen 5.0.0, lógica de segurança existente há muito tempo foi quebrada, resultando em CVE-2025-23395 e CVE-2025-46803
• Antes de novas refatorações, é necessário um conjunto de testes que permita verificar as propriedades de segurança da implementação
• Desenvolvedores que lidam com binários setuid-root precisam entender os riscos dessa área
• O Screen continua rodando com privilégios elevados e só reduz privilégios seletivamente em operações consideradas perigosas
• Um programa setuid-root robusto deveria reduzir privilégios por padrão e elevá-los apenas nas operações que realmente exigem privilégios elevados
• Em contexto setuid-root, é necessária lógica para remover todas as variáveis de ambiente, exceto as explicitamente permitidas
• Variáveis como PATH devem ser saneadas para apontar apenas para diretórios de sistema confiáveis
• No momento, a recomendação é não instalar como setuid-root não só o Screen 5.0.0, mas também a série anterior 4.9
• Como alternativa, o recurso multiusuário pode ser oferecido em modelo opt-in e permitir que apenas membros de grupos confiáveis executem uma versão multiusuário do Screen

Processo de coordenação da divulgação e estado do upstream

• Em fevereiro de 2025, os problemas foram reportados em privado ao upstream do Screen, junto com uma proposta de divulgação coordenada
• O upstream demonstrou interesse em manter os problemas em sigilo até corrigir os bugs antes da divulgação pública e informou precisar de 1 a 2 meses
• Cerca de um mês depois, começaram atividades do lado upstream e discussões sobre patches, mas as conversas não foram suficientemente produtivas
• Até perto do limite máximo de 90 dias de embargo, não houve comunicação adicional e, nesse meio-tempo, distribuições como NetBSD atualizaram para o Screen 5.0.0, ficando totalmente expostas ao CVE-2025-23395
• Concluiu-se que o upstream não estava suficientemente familiarizado com a base de código do Screen e não compreendia totalmente os problemas de segurança relatados
• O upstream queria divulgação mais cedo mesmo com alguns problemas ainda sem solução, então um rascunho foi enviado rapidamente para a mailing list distros
• Depois disso, a SUSE desenvolveu diretamente correções que faltavam e também ajustou e documentou patches discutidos em forma de rascunho no upstream
• Avaliou-se que, com capacidade upstream dedicada, o processo de divulgação coordenada poderia ter sido concluído em cerca de duas semanas
• O upstream do Screen aparentemente sofre com falta de pessoal e de especialização, o que é preocupante para um utilitário open source amplamente utilizado

Principais datas

• 2024-07-01: envio do pedido de revisão pelo upstream
• 2025-01-08: início do trabalho de revisão de segurança
• 2025-02-07: reporte privado ao upstream do Screen e proposta de divulgação coordenada
• 2025-02-11: criação de bug privado no rastreador GNU Savannah
• 2025-04-30: decisão de atribuição de CVEs e compartilhamento do rascunho na mailing list distros
• 2025-05-07: compartilhamento da versão final dos patches para Screen 4.9.1 e 5.0.0 com a mailing list distros e o upstream
• 2025-05-12: publicação do relatório no blog e na mailing list oss-security

[GN⁺]

Opiniões no Hacker News

• Eu não sabia que o Screen tinha esse modo multiusuário, mas provavelmente é esse recurso que torna possíveis ferramentas como o tmate.
  Com as credenciais adequadas, é possível anexar-se a uma sessão do Screen pertencente a outro usuário, e dizem que esse recurso só é possível quando o Screen está instalado como setuid-root.
  Então fiquei curioso se o tmux também é afetado pelo mesmo tipo de vulnerabilidade.

  • O tmux não se aplica a isso porque usa sockets de domínio Unix.
    Não sei por que o screen escolheu a abordagem setuid aqui; parece que não há nenhuma necessidade de privilégios de root.
    Mais abaixo no texto há uma explicação plausível de que os desenvolvedores atuais do screen não estão totalmente familiarizados com a base de código; se for isso, é possível que setuid-root tenha sido o jeito mais fácil de fazer o recurso funcionar.
  • É um recurso bem excelente.
    Em sessões de treinamento, eu já dei uma conta de login no meu laptop para cada aluno, limitei o shell SSH a screen -x e usei as listas de controle de acesso do screen para fazer cada aluno usar apenas a própria janela.
    Durante o exercício, como dono do screen, eu podia colocar a tela de cada aluno no projetor para a turma toda ver o resultado.
    Não me surpreenderia se houvesse muitas brechas de segurança.
  • Isso mesmo, screen -x

• No Debian, o GNU screen não é instalado com privilégios setuid-root.

  • O pacote do Debian Stable, ou seja, do bookworm, é antigo demais para ser afetado pela vulnerabilidade da versão 5.0.0.
    Antigamente eu odiava o fato de o Debian estar sempre atrasado nas versões dos softwares, mas hoje uso outras fontes de pacotes só para alguns apps dos quais realmente não quero depender em versões muito antigas, como o navegador, e fico bem com pacotes antigos para o resto.
  • No Slackware 15, /usr/bin/screen aponta para screen-4.9.0, e o executável também não é suid.
  • No Gentoo é a mesma coisa.
    Porém, no Gentoo, ele tem SETGID para o grupo utmp, e não sei bem qual é o impacto disso.
  • No Fedora, parece ser setuid-root.

• O post renderizado do blog está aqui: https://security.opensuse.org/2025/05/12/screen-security-iss...

• Já enviei um e-mail ao autor do GNU Screen dizendo que a documentação do recurso de logging em arquivo era inadequada: http://www.zoobab.com/screenrc
  O GNU precisa de um sistema melhor de acompanhamento de issues.

  • Houve uma sessão de perguntas e respostas com o autor do Tmux em que ele já reclamava da falta de documentação cerca de 16 anos atrás.
    https://undeadly.org/cgi?action=article&sid=20090712190402
  • Isso está documentado em detalhes no manual do GNU screen: https://www.gnu.org/software/screen/manual/screen.html#Log
  • Muitos projetos antigos têm o problema de que issues acabam enterradas nas profundezas intermináveis de listas de e-mail não indexadas.
    É justo criticar o Discord por tornar esse tipo de informação inacessível, mas o IRC que alguns projetos ainda usam é, na prática, duas vezes pior.
    Seria bom se esses projetos migrassem para lugares como Gitea, Forgejo, Codeberg, GitLab ou GitHub, reunindo os conteúdos relacionados em um só lugar e garantindo descobribilidade.

• O Zellij é uma alternativa moderna bem boa ao screen e ao tmux, tem ótimos padrões e foi bem projetado para tornar a UI fácil de descobrir.
  Recomendo para quem sentia que o custo-benefício de usar um multiplexador de terminal era meio duvidoso.
  https://zellij.dev
  https://github.com/zellij-org/zellij

  • Usei alguns anos atrás e achei bem polido.
    Mas, em comparação com o tmux, a latência era perceptível, e continuo usando tmux até hoje.
    Na época eu já estava em uma conexão com latência, então talvez eu estivesse um pouco sensível a isso.
  • Da última vez que vi o Zellij, ele parecia um ótimo projeto novo no ecossistema de multiplexadores, mas não oferecia suporte a um mecanismo de copiar/colar puramente baseado no teclado.
    Uso muito esse recurso, então não consigo ficar sem ele; até que seja adicionado, não tenho escolha a não ser usar tmux.
  • É bom, mas eu gosto muito do screen e os comandos já estão gravados na memória muscular.
    Uso há mais de 20 anos.

• É surpreendente que o upstream tenha se envolvido nisso.
  Uns 5 anos atrás, eu tinha concluído com tristeza que o desenvolvimento do GNU screen estava completamente parado; fico me perguntando se ainda não é esse o caso.
  Nem sei se o screen ainda tem o recurso de adicionar uma nova janela sem se anexar a uma sessão screen existente.

  • O upstream pediu à equipe da SUSE que desse uma olhada.
    Parece haver falta de desenvolvedores, e talvez o upstream não tenha a expertise para manter o projeto adequadamente.
    Se for verdade, é triste. Sei que existem tmux e outras alternativas, mas muita gente usa o Screen há muito tempo, e é uma pena ver uma ferramenta apodrecer lentamente.
  • O texto diz que, pela dificuldade de comunicação com o upstream, eles não têm atualmente informações detalhadas sobre as correções de bugs e releases feitas por lá.
    Parece que eles solicitaram uma revisão de segurança, mas tiveram dificuldade em manter contato, e não conheço todo o contexto.
  • O envolvimento foi basicamente distribuí-lo como setuid-root.
    As distribuições configuradas assim são vulneráveis, e as que não são, não são vulneráveis.
    Vejo isso como um envolvimento bem superficial. Se o upstream é lento demais, a distribuição aplica patches.
  • O desenvolvimento de ferramentas GNU parar não é necessariamente triste — exceto, claro, por correções de bugs.
    Pode ser visto basicamente como um sinal de que é uma ferramenta concluída.
  • No open source, há um problema de inércia quando um software chega ao fim e outro é criado para substituí-lo.
    Não há incentivo para mudar imediatamente, porque não é uma atualização, é uma migração.
    Por outro lado, também é ruim quando alguém compra a marca de um software existente e o transforma em algo completamente diferente, como aconteceu com o Audacity.
    Por isso, não parece haver uma boa solução.

• Versão renderizada: https://security.opensuse.org/2025/05/12/screen-security-iss...

• Se minha memória não falha, o tmux entrou no sistema-base a partir do OpenBSD 4.6 e é uma ferramenta que foi, ou vem sendo, auditada.
  É uma boa opção para quem quer uma alternativa um pouco mais segura.

  • Ver o screen aparecer de novo me lembra a época em que migrei para o tmux e depois acabei esquecendo do screen.

• O comportamento observado existia nas versões do Screen pelo menos desde 2005, e já era um antipadrão havia todo esse tempo; ferramentas como o rkhunter também lidavam com isso.
  Ainda assim, acho que o screen já era setuid root nos anos 90.

• Quantos desenvolvedores, de fato, mantêm as ferramentas open source mais populares?
  Quanto dinheiro há nas indústrias que usam essas ferramentas?