Vulnerabilidade do Telegram Desktop permitia roubar arquivos de qualquer usuário

Artigo original ↗ Discussão no Hacker News ↗

Uma falha recentemente corrigida no cliente desktop do Telegram permitia que um único link clicado exfiltrasse qualquer arquivo acessível ao usuário na máquina e sequestrasse a conta Telegram da vítima, reacendendo alertas sobre a postura de segurança do app. Comentadores contrastam a UX polida do Telegram e seus recursos poderosos de grupos/canais com a ausência de criptografia ponta a ponta por padrão, a identidade baseada em número de telefone e a infraestrutura opaca, muitas vezes preferindo alternativas como Signal ou WhatsApp para privacidade. O incidente também alimenta críticas mais amplas a sistemas operacionais desktop que permitem, por padrão, que apps leiam todos os arquivos do usuário, e provoca pedidos por sandboxing mais forte e modelos de ameaça mais cautelosos, especialmente diante de suspeitas sobre os vínculos do Telegram com interesses russos.

Escopo e gravidade do bug do Telegram Desktop

  • Comentadores enfatizam que, além da tomada de conta, o bug permitia a exfiltração de qualquer arquivo acessível ao usuário (chaves SSH, lojas do navegador, credenciais de nuvem etc.).
  • A causa raiz é discutida como um esquema interno de URL oculto que podia enviar arquivos arbitrários, criado para facilitar a publicação de releases do próprio Telegram.
  • Alguns consideram esse “recurso” de uma imprudência espantosa; outros observam que explorá-lo exigia uma cadeia um pouco complicada.

Design do SO, sandboxing e culpa

  • Uma visão: isso reflete um problema mais amplo dos sistemas operacionais desktop, em que qualquer processo de usuário pode ler qualquer arquivo do usuário; os apps deveriam ser isolados em diretórios por aplicativo.
  • Visão contrária: esta é claramente uma vulnerabilidade específica do Telegram; a maioria dos apps não faz upload secreto de arquivos arbitrários.
  • Vários mecanismos de sandbox são mencionados: unveil do OpenBSD, bubblewrap do Linux, SELinux, sandboxes do Flatpak, do macOS e da Windows Store, jails do FreeBSD, VMs no estilo Qubes.
  • Vários usuários já isolam navegadores/Telegram com firejail, VMs, usuários separados ou Flatpak, mas observam que sandboxes opcionais só ajudam quando os apps os usam.

Postura de segurança e escolhas de design do Telegram

  • Muitos reiteram que o Telegram há muito é criticado como “inseguro por design”: sem E2EE por padrão, identidade baseada em número de telefone, servidor fechado, escolhas criptográficas estranhas e bugs controversos no passado.
  • Críticas de que os clientes desktop ainda não suportam corretamente chats secretos e de que, supostamente, as configurações são reativadas silenciosamente.
  • Alguns argumentam que o Telegram não deveria ser considerado um “mensageiro seguro” de forma alguma; outros dizem que todos os clientes complexos têm bugs.

Por que as pessoas ainda usam o Telegram

  • Grande elogio à UX do Telegram: ferramentas poderosas de grupos, bots, formatação, transcrição de voz, paridade entre plataformas e armazenamento em nuvem efetivamente ilimitado.
  • Alguns aceitam compromissos de segurança porque veem agências de inteligência como uma ameaça menor que corretores de dados de ad-tech, ou porque todas as pessoas que precisam alcançar estão lá.
  • Outros dizem que o usam principalmente para canais públicos, clubes e makerspaces, onde a falta de E2EE importa menos.

Modelos de ameaça, geopolítica e confiança

  • Forte desconfiança dos vínculos do Telegram com Rússia e Dubai; alguns o veem como um provável ou de fato honeypot de inteligência.
  • Outros reagem contra julgar apenas pelo país de origem, mas ainda se preocupam com a retenção centralizada de todo o conteúdo/metadados.
  • Contraste com Signal e, em menor grau, WhatsApp: E2EE por padrão, clientes abertos (no caso do Signal) e modelos de negócio diferentes são vistos como materialmente melhores.

E2EE, web apps e atualizações

  • Longas discussões em subthreads sobre se E2EE verdadeiro é possível em web apps:
    • Um lado: clientes baseados em navegador não podem ser fixados ou auditados independentemente por usuário; o servidor pode trocar o código silenciosamente, minando toda a ideia de não confiar no servidor.
    • Outro lado: apps nativos com atualizações automáticas enfrentam risco semelhante; segurança real também depende de modelos de atualização/assinatura e de comprometimento do dispositivo.
  • Alguns observam que wrappers desktop no estilo Electron podem ao menos ter hash verificado e builds reprodutíveis, ao contrário do código vivo da web.

Lições mais amplas sobre permissões de apps

  • Apelos repetidos para parar de permitir que apps arbitrários, por padrão, leiam todo o diretório home e façam conexões de rede irrestritas.
  • Sugestões: controles em nível de sistema operacional, fáceis de usar, sobre acesso ao sistema de arquivos/rede, modelos de negação por padrão com opt-outs claros e tratar apps comerciais de código fechado (Zoom, Steam, Dropbox, Telegram) como não confiáveis e sempre isolados em sandbox.