Bug do macOS 14 Sonoma impede o funcionamento do app Mullvad VPN

 (mullvad.net)
1 pontos por GN⁺ 2023-09-14 | 1 comentários | Compartilhar no WhatsApp
  • Nas versões beta e release candidate do macOS 14 Sonoma, o firewall PF não filtra corretamente o tráfego, impedindo que o app Mullvad VPN funcione normalmente
  • Quando algumas configurações, como compartilhamento de rede local, estão ativadas, isso pode levar a vazamentos de tráfego; por isso, a Mullvad considera difícil garantir funcionalidade e segurança no macOS 14
  • A Mullvad investigou o problema após o sexto beta e o reportou à Apple, mas o bug permaneceu nos betas seguintes e no release candidate
  • A empresa avaliou se seria possível contornar o problema com um patch no próprio app, mas não encontrou uma solução segura; fundamentalmente, é necessária uma correção no firewall pela Apple
  • Usuários que dependem da filtragem PF, ou apps relacionados, devem ter cautela ao atualizar para o macOS 14; se o bug persistir, é mais seguro permanecer no macOS 13 Ventura

Problema no firewall PF do macOS 14 Sonoma

  • Durante o período beta do macOS 14 Sonoma, a Apple introduziu um bug no packet filter(PF), o firewall do macOS
  • Por causa desse bug, o app Mullvad VPN não funciona, e pode ocorrer vazamento de tráfego quando determinadas configurações estão ativadas
    • O compartilhamento de rede local foi citado como exemplo de configuração
  • A Mullvad investigou o problema depois do lançamento do sexto beta do macOS 14 e reportou o bug à Apple
  • O mesmo problema continuou presente nos betas posteriores do macOS 14 e no release candidate
  • A empresa avaliou uma forma de corrigir apenas o app de VPN para manter tanto o funcionamento quanto a segurança no macOS 14, mas concluiu que, no momento, não há uma boa solução
  • O impacto não se limita ao app Mullvad VPN
    • As regras de firewall não são aplicadas corretamente ao tráfego de rede
    • Tráfego que não deveria ser permitido pode passar
    • Usuários que dependem da filtragem PF, ou apps que a utilizam em segundo plano, devem ter cautela ao atualizar para o macOS 14
  • O macOS 14 Sonoma tem lançamento previsto para 26 de setembro e, se o bug permanecer, recomenda-se que usuários da Mullvad fiquem no macOS 13 Ventura até que haja uma correção

Etapas de reprodução e resultado real

  • O problema pode ser reproduzido no macOS 14, e este experimento remove as regras de firewall carregadas no PF
  • No Terminal, crie uma interface virtual de logging e monitore o tráfego que corresponda às regras que serão adicionadas depois
sudo ifconfig pflog1 create
sudo tcpdump -nnn -e -ttt -i pflog1
  • Escreva as seguintes regras de firewall no arquivo pfrules
pass quick log (all, to pflog1) inet from any to 127.0.0.1
block drop quick log (all, to pflog1)
  • Em outro Terminal, ative o PF e carregue as regras
sudo pfctl -e
sudo pfctl -f pfrules

ping 45.83.223.209
  • O resultado esperado é que o ping seja bloqueado por não corresponder à condição da única regra pass, e que o tráfego seja registrado em pflog1 como correspondente à regra block
  • Na prática, o ping sai para a internet e a resposta retorna, sem que o tráfego seja registrado em pflog1
  • Após o experimento, desative o firewall e limpe todas as regras
sudo pfctl -d
sudo pfctl -f /etc/pf.conf

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-14
Opiniões no Hacker News

  • O mesmo bug do PF também está quebrando um dos recursos de rede do OrbStack.
    Quando cheguei a isolar a causa até aqui, foi difícil acreditar, mas parece que não sou o único passando por isso. Espero muito que seja corrigido antes do lançamento da versão estável.
    Só consegui reportar à Apple ontem, mas parece uma regressão bem recente, provavelmente surgida por volta do beta 6.
    O PF originalmente deveria ser um firewall em que se aplica a última regra correspondente, mas o macOS parece estar se comportando quase como se valesse a primeira regra correspondente. Uma regra block no começo sobrescreve regras pass de outros anchors mesmo sem quick, o que obviamente causa problemas.

    • “Espero muito” ainda é pouco. Isso precisa obrigatoriamente ser corrigido antes do lançamento.
      Se a versão estável sair nesse estado, será inaceitável e, para mim, pessoalmente, será um motivo para abandonar o Mac OS. Se querem que ele seja usado para trabalho sério, não podem lançar um produto com uma regressão dessas.

  • O texto é bem conciso e útil, e gostei que inclui até passos simples para reproduzir o bug.
    Gosto da Mullvad.
    À parte, o macOS teve, de modo geral, muitos bugs estranhos de firewall nas últimas versões, e fico curioso para saber por que tiveram de refazer essa parte do firewall do zero.

    • A reescrita certamente teve relação com a migração forçada, na passagem do Catalina para o Big Sur, de extensões de kernel para System Extensions em espaço de usuário, especialmente NetworkExtension: https://developer.apple.com/documentation/networkextension
    • Se bugs assim na plataforma do sistema operacional local preocupam você, também dá para considerar abstrair o ponto de acesso local com um navegador remoto.
      Seja qual for a máquina local e o sistema operacional, é possível encaminhar a navegação por um servidor dedicado. Isso não encapsula toda a conexão de rede, apenas a navegação, mas, dentro desse escopo, permite trocar o endereço IP, ocultar a localização e acrescentar proteção contra zero-days de navegador.
      No BrowserBox, seguimos adicionando recursos que respeitam e protegem a privacidade e melhoram a experiência como um todo. Como é open source, você também pode modificá-lo como quiser. Se não gostar da AGPL-3.0, também há licença comercial: https://github.com/dosyago/BrowserBoxPro
      Se você não gosta de open source e prefere o conforto de uma grande empresa, parece que a Mullvad também tem o Mullvad Browser, que faz algo parecido.
    • Teria sido ainda melhor se também incluíssem o número do rdar/Feedback.
    • O macOS tentou evoluir a pilha de rede por anos, mas, quando surgiam regressões, acabava voltando atrás.
      Um texto antigo relacionado: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

  • Esse código de reprodução é realmente muito bom de ver.

    • Além de ser simples, é especialmente bom por incluir até a etapa de limpeza. É algo que costuma faltar em procedimentos de reprodução desse tipo.
    • Parece que é só configurar uma regra simples de firewall e tentar fazer uma consulta que viola essa regra.
      Claro, esse é o escopo do bug, mas não me parece que esse teste seja particularmente sofisticado ou bonito.

  • Não sei se está relacionado, mas, logo após as duas atualizações do macOS mais recentes, a rede não funcionava.
    Eu conseguia conectar ao Wi‑Fi, Ethernet e hotspot, mas nenhuma conexão real, como navegador ou ping, funcionava, e nem o roteador era alcançável.
    Nas duas vezes, bastou abrir uma vez o app Mullvad VPN para tudo voltar a funcionar. Não sei por que só abrir o app corrigia o problema.

    • O app de VPN altera a tabela de roteamento, então parece que, até você iniciar o app de VPN, o tráfego estava sendo roteado para uma interface inexistente.

  • Não é totalmente relacionado, mas há também outro bug antigo: o bug de 11 anos do Popen() no macOS: https://news.ycombinator.com/item?id=37238433

    • Se o bug é seu, é melhor também enviar um Feedback com um patch. Projetos open source geralmente não aceitam PRs.

  • Para constar, eu tive problemas de conexão com o Mullvad.app, mas, ao executar a configuração Mullvad WireGuard no Wireguard.app, funcionou bem.

  • Instalei recentemente o Sonoma beta mais novo e agora entendo por que não consegui fazer o Mullvad funcionar de jeito nenhum.
    Que bom que a Mullvad está trabalhando em uma solução de contorno. Hoje de manhã eu até pensei em fazer downgrade para o Ventura, mas agora sinto que meu problema era esse mesmo.

    • Não está escrito que estão trabalhando em uma solução de contorno. Dizem para os usuários não atualizarem para o Sonoma até a Apple corrigir o bug.
    • A combinação tailscale/mullvad provavelmente ainda funciona. Pode ser uma boa solução de contorno até a Apple corrigir.

  • Fico feliz que a Mullvad esteja aumentando a pressão pública sobre esse problema. Esse bug certamente chamou atenção e foi bastante preocupante.

    • Isso já era conhecido em outros lugares? Parece que a Mullvad reportou depois do 6º beta, e a essa altura já estava bem perto do RC.
      No original está escrito “we have investigated this issue after the 6th beta was released and reported the bug to Apple”.

  • No meu caso, a solução foi baixar a configuração do WireGuard e usar o app Wireguard.

    • Mas o app Wireguard não faz os dados vazarem e é menos seguro que o app da Mullvad?
    • Só é uma solução se você não colocar regras de firewall PostUp e PostDown na configuração do WireGuard. Nesse caso, fica difícil chamar isso de solução.

  • Pergunta: se pflog1 não for criado, o pf funciona como esperado?
    Se o tcpdump não registra nada saindo por pflog1, isso parece significar que os dados não estão sendo enviados para pflog1. Então o problema estaria em uma etapa anterior.
    O pflog1 estava conectado e ativo? Antigamente era preciso conectar e ativar a interface manualmente. O MacOS faz isso automaticamente?
    Claro que isolar isso não é trabalho de quem reportou o bug. Mas, em algum momento, o engenheiro responsável vai fazer esse tipo de pergunta, então é melhor já ter as respostas.

    • Há algo que possa ser acrescentado ao procedimento de reprodução como solução de contorno? Por exemplo, como mencionado, conectar e ativar a interface depois de carregar as pfrules.
    • Depois, para remover a interface adicional, também é preciso fazer isto:
      ifconfig pflog1 destroy