StarDict envia a área de transferência do X11 para um servidor remoto

• Foi descoberta uma falha de segurança grave em que o StarDict envia a seleção de texto do usuário em ambientes X11 para servidores externos por HTTP sem criptografia
• O problema ocorre porque os plugins YouDao e dict.cn vêm ativados por padrão na configuração padrão do Debian
• Isso significa que qualquer texto selecionado pelo usuário é enviado automaticamente ao servidor, com risco de vazamento de informações sensíveis
• O mantenedor do pacote analisou propostas para desativar a função e separar os plugins, mas a aplicação de uma solução definitiva foi insuficiente
• O problema já havia sido apontado várias vezes no passado, evidenciando novamente a ausência de uma resposta completa e a importância da conscientização sobre segurança

---

Visão geral do funcionamento do StarDict e do problema de segurança

• StarDict é um programa de dicionário multiplataforma sob licença GPLv3, com suporte a vários idiomas e um ecossistema de plugins
• Na configuração padrão do Debian, ao executar o StarDict, o texto selecionado pelo usuário é enviado para dois servidores remotos, youdao.com e dict.cn, por HTTP sem criptografia
• O problema também foi relatado na lista de discussão oss-security e no rastreador de bugs do Debian

Detalhes do problema

• Pelo design do StarDict, o código que se comunica com sites de dicionário é algo natural, mas a função de "scan" vem ativada por padrão
  • Isso significa que, quando o usuário seleciona texto com o mouse, um popup de tradução é exibido automaticamente e esse texto é enviado automaticamente para servidores externos
  • O problema se torna mais grave quando o usuário mantém o StarDict sempre em execução em segundo plano

Diferenças entre ambientes Linux

• Em ambientes Wayland, o StarDict não consegue capturar texto de outros aplicativos, então a função de scan não funciona e o problema de segurança não ocorre
• Esse problema existe atualmente apenas no ambiente X11 tradicional

Reação do Debian e dos desenvolvedores do StarDict

• O mantenedor do pacote Debian, Xiao Sheng Wen, afirmou que "a função de scan e o plugin YouDao podem ser desativados", sem tratar isso como um grande problema
• Porém, o autor do relatório, Vincent Lefevre, apontou que "funções relacionadas à privacidade devem vir desativadas por padrão"
• Embora a funcionalidade pudesse ser informada na descrição do pacote, a descrição do stardict-plugin não menciona o uso de dicionários online
• Houve propostas de melhoria, como a separação dos plugins, mas nenhuma medida imediata foi tomada

Conveniência da função e preocupações de segurança

• A função de scan é uma vantagem importante do StarDict para quem quer consultar rapidamente um dicionário ao ler em língua estrangeira
• No entanto, é difícil para o usuário imaginar que essa comunicação não é criptografada. Qualquer pessoa no caminho pode ter acesso a texto sensível

Incidentes semelhantes no passado e resposta ao problema

• Casos semelhantes já foram relatados em 2009 e 2015
  • 2009: a desativação de dicionários em rede foi aplicada temporariamente como padrão
  • Porém, o plugin YouDao, adicionado em 2016, ignorava essa configuração
  • O problema de 2015 só foi resolvido em 2025 na forma de remoção do plugin
• Isso mostra a repetição do retorno do problema e da demora na resposta, além de trocas de mantenedor e falhas de priorização

Tamanho da base de usuários e impacto de segurança

• Segundo as estatísticas do Debian, atualmente apenas cerca de 178 pessoas têm o StarDict instalado, mas, considerando sistemas que não participam das estatísticas, muitos usuários podem ter ficado expostos ao risco de vazamento de texto ao longo dos anos
• Cópia de senhas, e-mails sensíveis e texto selecionado durante a edição de documentos, por exemplo, poderiam ser expostos a terceiros

Ecossistema open source e agenda de segurança

• Grandes distribuições como o Debian gerenciam inúmeros pacotes, e atualizações perdidas e envelhecimento de software são frequentes
• A Lei de Linus, segundo a qual "com olhos suficientes, todos os bugs são triviais", só funciona na prática quando alguém encontra o bug, o relata, e o mantenedor reconhece e corrige o problema

A mudança do X11 para o Wayland

• A adoção do Wayland busca reduzir esse tipo de falha de segurança, especialmente a possibilidade de vazamento de informações entre aplicativos
• Ainda assim, permanecem desafios como limitações funcionais e novas formas de lidar com permissões de uso

Conclusão e implicações

• É preocupante que problemas de segurança descobertos, diagnosticados e relatados continuem sem solução ou voltem a ocorrer
• Para preservar a reputação de segurança do Linux, é essencial que desenvolvedores open source, mantenedores de pacotes e usuários mantenham atenção constante ao problema e respondam com rapidez

[GN⁺]

Comentários do Hacker News

• Como Xiao apontou, quem instala o software pode ler a descrição do pacote, e a função de varredura de fato é mencionada. Mas mantenedores do Debian frequentemente respondem relatórios de bug com algo na linha de “você precisa ler cuidadosamente todas as descrições de todos os pacotes (inclusive as centenas instaladas como dependência)”; sinceramente, se alguém tivesse começado a ler todas as descrições e READMEs no Trixie, lançado há poucos dias, provavelmente ainda não teria terminado

  • “As plantas e ordens de demolição estavam expostas no escritório local de Alpha Centauri por cinquenta anos no tempo de vocês da Terra. Se vocês não se interessam pelos assuntos locais...” essa parte parece certeira link do vídeo no YouTube
  • Quando vem uma resposta desse tipo, eu só consigo interpretar como má-fé
  • Quando instalo um programa do repositório Debian, é pela conveniência e pela confiança. Já reclamo bastante quando mantenedores alteram o comportamento do pacote, mas teria sido muito melhor se esse recurso de enviar dados da área de transferência para terceiros fosse opt-in, ou seja, algo que a pessoa ativasse explicitamente. Isso quebra a confiança
  • Concordo que, no lançamento do Trixie, ler todas as descrições de pacotes e READMEs é inviável. Quando usei Debian pela primeira vez no fim dos anos 90 e começo dos anos 2000, dava para escolher os pacotes no dselect e, investindo algumas horas, ajustar todas as opções ao hardware real (na época não era tão dinâmico como hoje, então precisava selecionar cada opção manualmente). Hoje há pacotes demais, e a configuração do kernel ficou ampla demais para ser realisticamente auditada por completo (ainda existe gente usando dselect...?)
  • Concordo com você. Principalmente porque esse mantenedor já criou comportamentos inesperados várias vezes; como no problema anterior, ele continuou repetindo a prática inadequada de alterar até arquivos de configuração de outros pacotes. Isso deveria ser removido do repositório

• Claro, pode-se presumir que um programa de dicionário inclua código para se comunicar com sites. Mas se eu instalo um dicionário com apt-get, posso esperar ter o dicionário inteiro no meu computador. Afinal, usamos dicionários de papel há séculos... O Stardict é mais voltado ao online, então talvez seja normal, mas ainda parece uma armadilha

  • Acho que isso é diferença geracional. Quem acha natural que um app se comunique com a internet hoje em dia é a geração mais nova, que não está acostumada com software instalado localmente e sem comunicação externa. Mesmo olhando o histórico do desenvolvedor, dá para ver que ele entende bastante de ciência da computação e sabe perfeitamente que um dicionário offline é possível, mas parece estar seguindo o “normal” da geração dele. É triste que, no mundo atual, apps instalados localmente e que funcionam só com dados offline pareçam uma espécie de cavalheirismo mantido por um pequeno grupo de quixotes da TI
  • Mesmo que fosse normal, usar HTTP sem criptografia seria totalmente inaceitável
  • O antigo programa ding oferece suporte muito bom a dicionários locais. Também está no Debian link do ding
  • Isso também me chamou atenção. É triste viver num mundo em que até uma função simples dessas é esperada como serviço online
  • Em algum momento passei a executar apps GUI sem acesso à rede. Primeiro com firejail, depois com bubblewrap, e com o tempo com scripts bash que fiz para rodar apps em sandbox. Faço isso desde antes do flatpak

• Fiquei bem surpreso ao descobrir que, em celulares Samsung, todos os dados da área de transferência são compartilhados entre todos os dispositivos da minha conta Samsung (incluindo senhas), e ainda ficam no histórico. Não lembro se era a configuração padrão ou se aceitei isso por acaso. Imagino que esses dados passem pelos servidores da Samsung. Desativei o compartilhamento, mas o histórico da área de transferência não desliga, e mesmo trocando de teclado, se eu voltar ao teclado da Samsung, todo o histórico antigo continua lá. Meu próximo celular não deve ser Samsung

  • Pelo que sei, as TVs da Samsung também compartilham histórico de uso e dados pessoais com empresas de marketing. A política de privacidade da Samsung é a mesma tanto para telefone quanto para TV
  • Já vi senhas copiadas no Linux aparecerem no histórico da área de transferência do Android via KDE Connect. Gostaria de saber se existe um jeito de impedir especificamente isso para senhas sem desativar completamente o compartilhamento da área de transferência
  • Ao usar um dispositivo Samsung, recomendo nem criar nem fazer login em uma conta Samsung. Isso reduz bastante a chance de a empresa acessar seus dados

• Acho que há um pouco de confusão na discussão sobre o Wayland. O resumo final está correto: “talvez o StarDict tenha pedido permissões especiais para funcionar no Wayland, e o usuário provavelmente teria aceitado o padrão, como faz agora.” Ou seja, isso parece bem plausível, e essas permissões podem até ter sido configuradas automaticamente durante a instalação. Malware sempre vai existir. O Wayland pode bloquear alguns tipos de ataque, mas não vai proteger contra um pacote instalado como parte da distribuição

  • Não é confusão: nesse aspecto, o Wayland é claramente melhor que o Xorg. Mas o cerne do problema é ainda mais estrutural. Por exemplo, os dados transmitidos nem sequer eram criptografados! No X11, com as configurações padrão do Debian, o StarDict envia por HTTP para dois servidores remotos o texto selecionado pelo usuário. Mesmo que a pessoa tivesse lido cuidadosamente a descrição do pacote ou o plugin do YouDao, no mínimo esperaria que a comunicação fosse criptografada. Mas na prática ele envia dados para os servidores dict.youdao.com e dict.cn por HTTP totalmente inseguro, e qualquer um no caminho pode ver o conteúdo das requisições

• Fazer consultas a dicionário local a partir da área de transferência tudo bem. Adicionar recurso de consulta a dicionário remoto também não tem problema. Combinar essas duas funções de forma fácil até seria aceitável se isso fosse separado por algum tipo de flag especial, mas misturar as duas no comportamento padrão chega perto de algo quase malicioso

  • Esse youdao de que estão falando aqui é um serviço de tradução. Tradução offline é muito inferior à online, então eu só quero usar algo como um pacote local de tradução offline do Google quando estiver sem dados. Não uso Stardict, mas para traduções mais amplas e não apenas significado de palavras, esse comportamento é perfeitamente previsível. No fim das contas, o ponto central da matéria inteira é: “um programa chinês de tradução enviou dados da área de transferência para o próprio site e para um serviço chinês de tradução, e fez isso por HTTP sem criptografia”

• Sobre a frase “claro que um programa de dicionário tem código ligado a sites”, eu diria que na prática isso depende do objetivo. A versão mínima do meu dicionário finlandês (tsk) tem cerca de 30 MB e inclui aproximadamente 250 mil palavras, com o dicionário embutido diretamente no binário, reconstruindo a busca por prefixo a cada execução. Mas um banco de dados enorme com lematização, etimologia etc. pode crescer para dezenas de gigabytes. Como meu objetivo era navegação completamente imediata a cada tecla digitada, eu precisava dessa estrutura. Deu bastante trabalho, então decidi cobrar pelas versões seguintes Github do tsk site da versão paga (atualmente offline por causa de um problema com assinatura de código no Windows). Para a maioria dos outros casos de uso, consultar um servidor é muito mais prático. Como quase nunca faz sentido baixar um dicionário gigantesco inteiro, uma estrutura híbrida (por exemplo, cache local das 10 mil palavras mais comuns e consulta ao servidor para palavras raras) também parece bastante razoável

• Ao ver isso, há vários pontos que me fazem pensar que só pode ter havido má intenção. O mantenedor respondeu: “o usuário ativou manualmente a função de ‘scan’, e selecionar texto dispara a tradução... então por que selecionar dados confidenciais como consulta de tradução?”

  • Será que o mantenedor não consegue distinguir quando há segredo em idioma estrangeiro...? Por exemplo, se estiver escrito “秘密”. “Chefe, o inimigo está enfrentando erros no servidor de tradução!”

• Respeito muito o esforço colocado no Debian, mas sempre detestei esse “maximalismo” do gerenciador de pacotes. Por exemplo, você tenta instalar foo e ele puxa todo software possivelmente relacionado, e se houver um daemon de rede no meio, já sai executando também. Eu sei que existe flag para impedir a instalação de “pacotes recomendados”, mas sinto que o padrão acaba sendo inconveniente para o usuário

  • Com todo respeito, discordo. Recommends serve para ampliar os recursos principais do pacote instalado. Sem isso o pacote não fica quebrado, mas perde funcionalidades importantes. O pacote citado deveria ser classificado como Suggests, não como Recommends. Suggests não é instalado por padrão. Ao usar apt ou aptitude, há uma prévia da instalação e o usuário pode decidir. Existe uma tensão entre minimalismo e conveniência. No lançamento do Debian 13, também houve quem dissesse que “Debian definitivamente não é uma distribuição amigável ao usuário”. Pessoalmente, prefiro uma distro “estável, básica e amigável ao usuário” a uma “estilo IKEA faça-você-mesmo para faça-você-mesmo”. E usuários avançados sempre podem mudar isso quando quiserem. Se precisar alterar o padrão, dá para fazer em /etc/apt/conf.d/; para um caso pontual, basta usar --no-install-recommends
  • Esse é um dilema clássico de equilíbrio entre conveniência e segurança. O padrão de Recommends do Debian foi pensado numa época em que a rede não era uma constante e a funcionalidade local importava mais do que limites de segurança
  • Originalmente, o padrão de APT::Install-Recommends era false, e mudou para true no Debian 6.0 Squeeze (2011-02-06). Na época, eu detestava porque Debian e Ubuntu instalavam muitos pacotes desnecessários. Hoje, olhando para trás, acho que a distinção entre recomendados e sugeridos às vezes era ambígua, e talvez tenha sido melhor instalar Recommends por padrão e deixar o usuário optar por sair. Mesmo assim, nos sistemas que administro pessoalmente, ainda desativo a instalação automática de pacotes recomendados
  • Não tenho problema com --install-recommends ser o padrão. A distinção sutil entre Recommends como “a maioria de nós quer isso” e Suggests como “funcionalidade de nicho” não é ruim. Mas também acho problemático quando mantenedores individuais abusam do campo Recommends. Por exemplo, instalar uma ferramenta de compactação e ela puxar um sistema de init específico não faz sentido nenhum (estou olhando para file-roller e equipes relacionadas ao GNOME)
  • Por outro lado, também é ruim quando uma funcionalidade necessária vira opção opt-in e acaba faltando. O problema, mais do que instalar pacotes “recomendados”, é que as próprias recomendações de pacote deveriam ser mais conservadoras. Vale lembrar que o Debian já separa obrigação e opcionalidade entre recommended e suggested

• Não entendo por que tudo isso não é offline. Um dicionário completo de chinês tem menos de 400 mil palavras; mesmo estimando 1 KB por palavra, 400 MB bastariam. Dá perfeitamente para implementar isso localmente, então depender de conexão de rede é só projeto ruim

  • Então primeiro seria preciso um dicionário copyleft

• Ver esse tipo de problema me deixa furioso. Isso é absolutamente inaceitável

  • Queria dizer que você não está sozinho. É o tipo de situação que precisaria de algo para acordar as pessoas de vez, como quando jogaram torta no Bill Gates