Suspeita de bypass da criptografia de DNS no macOS Sequoia 15 era, na verdade, um problema do Little Snitch 6.1

 (obdev.at)
1 pontos por GN⁺ 2024-09-18 | 2 comentários | Compartilhar no WhatsApp
  • No Little Snitch 6.1, a criptografia de DNS podia falhar em algumas situações, mas o problema foi limitado a essa versão específica, não ao macOS como um todo, e foi corrigido na versão 6.1.1
  • Para funcionar normalmente, as solicitações de DNS do macOS precisam ser encaminhadas ao proxy de DNS do Little Snitch, e o proxy deve realizar consultas criptografadas
  • Durante a investigação, foi observado que algumas solicitações de APIs legadas de baixo nível não chegavam ao proxy e enviavam consultas UDP 53 sem criptografia para o servidor de nomes padrão do sistema
  • A reprodução consiste em ativar a criptografia de DNS no Little Snitch, executar o Wireshark com o filtro port 53 e depois chamar getaddrinfo("dnsproxytest.com") em um playground do Xcode
  • Consultas baseadas em APIs de alto nível, como as do Safari e do Chrome, inicialmente pareciam não ser afetadas, e o Firefox parecia ser afetado, mas o escopo final foi definido como um problema do proxy de DNS do Little Snitch 6.1

Falha na criptografia de DNS ocorrida no Little Snitch 6.1

  • O recurso de criptografia de DNS do Little Snitch 6 roteia consultas de nomes de host pelo Little Snitch para processá-las de forma criptografada
  • Para isso, o Little Snitch registra um proxy de DNS, e o macOS deve enviar todas as solicitações de DNS para esse proxy
  • Foi descoberto que algumas solicitações de DNS, especialmente as feitas por certas APIs legadas de baixo nível, não eram recebidas pelo proxy
  • Essas solicitações podiam ser enviadas sem criptografia para o servidor de nomes padrão do sistema, e isso podia ser confirmado no Wireshark como tráfego UDP na porta 53
  • Esse tráfego de consulta não aparecia no Little Snitch Network Monitor, porque a consulta contornava completamente o filtro de rede

Procedimento de reprodução e histórico das atualizações

  • Procedimento de reprodução

    • Ative DNS encryption nas configurações do Little Snitch
    • Execute o Wireshark com o filtro de captura port 53
    • Em um playground do Xcode, execute uma consulta a dnsproxytest.com com getaddrinfo
    • A consulta a dnsproxytest.com pode aparecer sem criptografia no UDP 53

  • Escopo inicial do impacto

    • Consultas de DNS por APIs de alto nível pareciam não ser afetadas
    • A navegação na web no Safari e no Chrome parecia manter os benefícios das consultas criptografadas
    • O Firefox parecia ser afetado

  • Histórico de atualizações

    • 2024-09-17 19:10: Foi confirmado que esse problema pode existir desde o macOS 14.5 Sonoma, e não foi possível testar sistemas 14.x mais antigos
    • 2024-09-18 12:05: Foi concluído que não se tratava de um problema geral do proxy de DNS do macOS, mas de um problema que afetava apenas o proxy de DNS do Little Snitch 6.1
    • 2024-09-18 15:52: O problema foi corrigido no Little Snitch 6.1.1

Leituras relacionadas

2 comentários

 
GN⁺ 2024-09-18
Comentários do Hacker News

  • Parece um pouco estranho que getaddrinfo() seja tratado como uma “API legada de baixo nível”
    No macOS a situação pode ser bem diferente, mas no Linux e provavelmente nos *BSD ele é a forma padrão de fazer resolução de nomes
    A maioria dos apps no macOS provavelmente usa frameworks como Foundation ou NetworkKit para consultas DNS, mas também é surpreendente que internamente isso não acabe sendo processado por chamadas como getaddrinfo()
    Como o GAI é bloqueante, provavelmente existe alguma outra chamada assíncrona de baixo nível

    • Sim. CFNetwork é open source, então dá para verificar a implementação, e da última vez que vi, lembro que usava alguma variante como getaddrinfo_async
      No entanto, a Apple não quer que o usuário final resolva IPs diretamente via getaddrinfo ou pela variante assíncrona exposta pelo CF e depois faça connect() para esse IP
      De forma geral, eles incentivam conectar por hostname, para que a Apple possa cuidar internamente da implementação de happy eyeballs
      Dá para ver por que a Apple não prefere o modelo de getaddrinfo() em https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf. Também há notas do apresentador embaixo de cada slide
    • Não acho que getaddrinfo() seja considerado legado. Acho que aquele post do blog errou nessa parte
      Se é “baixo nível” ou não depende do ponto de vista
    • getaddrinfo() não é algo relacionado ao Linux; é apenas uma função da glibc
      As pessoas presumem que a glibc é a forma padrão do espaço de usuário no Linux, mas isso não precisa ser assim
      Por exemplo, o systemd criou seu próprio mecanismo resolved, e ele acabou se mostrando muito melhor do que o lado da glibc
      Eu também desenvolvo software independente para Linux, então é bem provável que um dia eu mesmo faça algo parecido
    • No OpenBSD, pelo menos, todas essas funções DNS tradicionais/padrão como getaddrinfo/gethostbyname são wrappers da implementação asr da libc do OpenBSD, escrita por Eric Faurot
      https://man.openbsd.org/man3/asr_run.3
      https://github.com/openbsd/src/tree/master/lib/libc/asr
    • Não sei se é exatamente o caso aqui, mas até funções de sistema com o mesmo nome podem ter implementações internas muito diferentes entre *Linux/BSD/macOS
      Também há diferenças entre os próprios *BSD
      Em alguns sistemas, uma chamada de função pode ser mantida por anos e ser a “forma correta”, enquanto em outros ela pode de fato estar ultrapassada e não ser útil

  • Descobriu-se que o problema tratado aqui não era do macOS como um todo, mas algo específico do Little Snitch 6.1, e deve ser corrigido mais tarde hoje em uma atualização do Little Snitch

    • Seria bom se o título também pudesse ser atualizado para refletir isso

  • Investigações adicionais mostraram que esse bug já existia pelo menos desde o macOS 14.5 Sonoma
    Talvez até antes, mas disseram que no momento não têm acesso a sistemas 14.x mais antigos para testar

    • Fico curioso se eles chegaram a testar se isso realmente funcionava no getaddrinfo
      Ou se viram funcionando uma vez no CFNetwork, encerraram por aí e depois publicaram um post de blog dizendo que quebrou
    • Ainda é absurdo que desenvolvedores precisem manter versões antigas do sistema operacional só para testar
      A Apple tem praticamente zero motivos técnicos para não permitir downgrade
    • Considerando que eles vendem o produto e que o novo sistema operacional saiu ontem, isso também é bem ridículo

  • No Sequoia, se o firewall do macOS estiver ativado e um app estiver marcado como “bloquear conexões de entrada”, isso quebra a capacidade desse app de usar DNS e provavelmente funcionalidades em UDP em geral
    https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

    • Não consigo reproduzir. Alguns dizem que isso está relacionado ao ESET: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...
    • Antes do Sequoia, mesmo usando OpenDNS na VPN, o iMessage e outros apps continuavam funcionando com a VPN conectada, mas depois do Sequoia, mensagens do iMessage e afins deixaram de funcionar durante a conexão VPN
      Se eu desligo a VPN, tudo volta a passar
      Fico me perguntando se isso está relacionado. O firewall do macOS está ligado, mas não com bloqueio de todas as conexões de entrada
    • Depois de atualizar para o Sequoia, eu não conseguia navegar com Safari nem Mozilla
      Entrei nas configurações de DNS da conexão Wi‑Fi e adicionei os servidores DNS do Google, 8.8.8.8 e 8.8.4.4, e isso resolveu, substituindo os servidores DNS que estavam preenchidos automaticamente
    • Sinceramente, eu até acho esse comportamento aceitável. Aplicativos não deveriam resolver DNS por conta própria fora do que está definido nas configurações
      Os apps fazem isso para impedir que usuários consigam bloquear coisas como telemetria
      O computador é meu, então a decisão final sobre o que sai dele deveria ser minha

  • O título sugere que isso é intencional ou aplicado de forma privilegiada à Apple, mas na prática parece estar mais para um bug
    Quando alguém reporta algo assim, seria bom incluir também o número do FB e os detalhes do relatório

    • Fazendo o papel de advogado do diabo, também dá para parecer um bug feito de propósito e nunca corrigido, para evitar reação negativa
      Se o objetivo for alcançado, a forma de implementação pode ser o quanto for flexível
    • Se fosse intencional, provavelmente seria uma URL hardcoded e criptografada
      Alguns dispositivos já começaram a usar esse método para contornar bloqueio de anúncios

  • Posso estar enganado, mas dá uma sensação de déjà vu ver problemas de DNS em todo novo lançamento de iOS ou Mac, afetando coisas como Little Snitch e Mullvad
    Se for verdade, realmente fica a dúvida sobre o que a Apple faz durante meses de testes para desenvolvedores e beta

  • A menção ao Little Snitch me confundiu, mas lendo mais parece um bug do LS que só acontece em casos específicos
    Se este é o blog do LS, a única dúvida é por que isso é retratado como se fosse um bug do macOS
    Não quer dizer que esteja errado; isso é mais a área deles do que a minha, mas só pelo texto não parece muito bem justificado

    • Se o SO permite registrar um proxy DNS e depois algumas chamadas ignoram esse proxy, então isso é claramente um bug do SO

  • Lembro que a Apple descontinuou o uso de certas APIs de rede para desenvolvedores terceiros
    Mas os próprios apps da Apple, por exemplo a App Store, não ficam sujeitos à mesma limitação
    Então, ao tentar filtrar o tráfego de rede por um firewall de aplicativo com a nova API, a App Store falhava por usar a API legada
    Isso pode ser parte de um bug antigo que eu achava que já tinha sido corrigido

    • getaddrinfo() não é uma API legada, e sim uma API padrão multiplataforma para consultas DNS

  • Anúncios do tipo “Bug encontrado na nova versão do SO! Correção: na verdade era um bug que já existia há bastante tempo!” são sempre divertidos

  • Eu uso routedns [0] como resolvedor stub local para escolher manualmente para onde enviar cada requisição e qual método de transporte usar
    Também dá para fazer listas de bloqueio, reescrita, cache, balanceamento de carga e tratamento de requisições de fallback, então há bastante controle
    Para requisições locais, uso um listener stub em localhost:53, e a maioria das requisições vai para o Cloudflare 1.1.1.1 via UDP QUIC com cache, ou seja, TLS 0-RTT
    É rápido e bastante seguro
    [0] https://github.com/folbricht/routedns
 
nearfall 2024-09-18

Obrigado pelas informações importantes.
Antes de mais nada, é um alívio saber que Safari e Chrome parecem estar seguros.