Un bug de macOS 14 Sonoma empêche l’application VPN de Mullvad de fonctionner

 (mullvad.net)
1 points par GN⁺ 2023-09-14 | 1 commentaires | Partager sur WhatsApp
  • Dans la bêta et la release candidate de macOS 14 Sonoma, le pare-feu PF ne filtre pas correctement le trafic, ce qui empêche l’application VPN de Mullvad de fonctionner normalement
  • Si certains réglages comme le partage du réseau local sont activés, cela peut entraîner des fuites de trafic, et Mullvad estime donc qu’il est difficile de garantir les fonctionnalités et la sécurité sur macOS 14
  • Mullvad a enquêté sur le problème après la 6e bêta et l’a signalé à Apple, mais le bug est toujours présent dans les bêtas suivantes et dans la release candidate
  • L’entreprise a examiné s’il était possible de contourner le problème via un correctif de l’application elle-même, mais n’a pas trouvé de solution sûre ; au fond, une correction du pare-feu par Apple est nécessaire
  • Les utilisateurs qui dépendent du filtrage PF ou les applications associées doivent faire preuve de prudence avant de passer à macOS 14 et, si le bug persiste, il est plus sûr de rester sur macOS 13 Ventura

Problème de pare-feu PF dans macOS 14 Sonoma

  • Pendant la période bêta de macOS 14 Sonoma, Apple a introduit un bug dans packet filter (PF), le pare-feu de macOS
  • À cause de ce bug, l’application VPN de Mullvad ne fonctionne pas et, si certains réglages sont activés, des fuites de trafic peuvent se produire
    • Le partage du réseau local est cité comme exemple de réglage
  • Mullvad a enquêté sur le problème après la sortie de la 6e bêta de macOS 14 et a signalé le bug à Apple
  • Le même problème persiste ensuite dans les bêtas de macOS 14 et dans la release candidate
  • Mullvad a évalué la possibilité de corriger uniquement l’application VPN afin de préserver à la fois le fonctionnement et la sécurité sur macOS 14, mais considère qu’il n’existe pour l’instant aucune bonne solution
  • La portée du problème ne se limite pas à l’application VPN de Mullvad
    • Les règles du pare-feu ne s’appliquent pas correctement au trafic réseau
    • Du trafic qui ne devrait pas être autorisé peut passer
    • Les utilisateurs qui dépendent du filtrage PF ou les applications qui l’utilisent en arrière-plan doivent être prudents avant de passer à macOS 14
  • La sortie de macOS 14 Sonoma est prévue pour le 26 septembre et, si le bug persiste, il est recommandé aux utilisateurs de Mullvad de rester sur macOS 13 Ventura jusqu’à ce qu’un correctif soit disponible

Étapes de reproduction et résultat réel

  • Le problème peut être reproduit sur macOS 14, et cette expérience efface les règles de pare-feu chargées dans PF
  • Dans le terminal, créez une interface de journalisation virtuelle, puis surveillez le trafic correspondant aux règles qui seront ajoutées ensuite
sudo ifconfig pflog1 create
sudo tcpdump -nnn -e -ttt -i pflog1
  • Écrivez les règles de pare-feu suivantes dans le fichier pfrules
pass quick log (all, to pflog1) inet from any to 127.0.0.1
block drop quick log (all, to pflog1)
  • Dans un autre terminal, activez PF et chargez les règles
sudo pfctl -e
sudo pfctl -f pfrules

ping 45.83.223.209
  • Le résultat attendu est que le ping soit bloqué, car il ne correspond pas aux conditions de l’unique règle pass, et que le trafic soit enregistré dans pflog1 comme correspondant à la règle block
  • En réalité, le ping part sur Internet et une réponse revient, tandis qu’aucun trafic n’est enregistré dans pflog1
  • Après l’expérience, désactivez le pare-feu et effacez toutes les règles
sudo pfctl -d
sudo pfctl -f /etc/pf.conf

À lire aussi

1 commentaires

 
GN⁺ 2023-09-14
Commentaires Hacker News

  • Le même bug de PF casse aussi une fonctionnalité réseau d’OrbStack.
    Quand j’ai réussi à isoler la cause jusque-là, j’avais du mal à y croire, mais il semble que je ne sois pas le seul. J’espère vraiment que ce sera corrigé avant la sortie de la version stable.
    Je n’ai pu le signaler à Apple qu’hier, mais cela ressemble à une régression assez récente, probablement apparue autour de la beta 6.
    PF est censé être un pare-feu où la dernière règle correspondante s’applique, mais macOS semble se comporter presque comme si la première règle correspondante l’emportait. Une règle block placée plus haut écrase des règles pass d’autres ancres même sans quick, ce qui pose évidemment problème.

    • « J’espère vraiment » ne suffit pas. Cela doit absolument être corrigé avant la sortie.
      Si la version stable sort dans cet état, ce serait inacceptable et, à titre personnel, ce serait une raison d’abandonner Mac OS. Si Apple veut que ce soit utilisé pour du travail sérieux, il ne faut pas livrer un produit avec ce genre de régression.

  • L’article est très concis et instructif, et j’apprécie qu’il inclue même des étapes de reproduction du bug simples.
    J’aime bien Mullvad.
    À côté de ça, macOS a eu pas mal de bugs étranges de pare-feu au fil des dernières versions, et je me demande pourquoi ils ont fini par refondre toute cette partie.

    • La réécriture a sûrement été influencée par la transition forcée, entre Catalina et Big Sur, des extensions noyau vers les System Extensions en espace utilisateur, en particulier NetworkExtension : https://developer.apple.com/documentation/networkextension
    • Si ce genre de bug sur une plateforme de système d’exploitation locale vous inquiète, vous pouvez aussi envisager d’abstraire le point d’accès local via un navigateur distant.
      Quelle que soit votre machine locale et votre système d’exploitation, vous pouvez faire passer la navigation par un serveur dédié. Cela n’englobe pas toute la connectivité réseau, seulement la navigation, mais dans ce périmètre cela permet de changer d’adresse IP, de masquer l’emplacement et d’ajouter une protection contre les zero-days de navigateur.
      BrowserBox continue d’ajouter des fonctions qui respectent et protègent la vie privée, tout en améliorant l’expérience globale. C’est open source, donc vous pouvez le modifier comme vous le souhaitez. Si l’AGPL-3.0 ne vous convient pas, une licence commerciale est aussi possible : https://github.com/dosyago/BrowserBoxPro
      Si vous n’aimez pas l’open source et préférez le confort d’une grande entreprise, Mullvad semble aussi proposer Mullvad Browser, qui fait quelque chose de similaire.
    • Cela aurait été encore mieux avec le numéro rdar/Feedback.
    • macOS essaie depuis des années de faire évoluer sa pile réseau, mais revient parfois en arrière quand des régressions apparaissent.
      Un ancien article lié : https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

  • Ce code de reproduction est vraiment agréable à lire.

    • Sa simplicité est appréciable, mais j’aime surtout qu’il inclue une étape de nettoyage. C’est un élément souvent absent dans ce type de procédure de reproduction.
    • J’ai l’impression qu’il ne fait que définir une règle de pare-feu simple puis tenter une requête qui enfreint cette règle.
      Bien sûr, c’est bien le périmètre du bug, mais je ne trouve pas ce test particulièrement sophistiqué ni élégant.

  • Je ne sais pas si c’est lié, mais juste après les deux dernières mises à niveau de macOS, le réseau ne fonctionnait plus.
    Je pouvais me connecter au Wi‑Fi, à l’Ethernet et au partage de connexion, mais aucune connexion réelle, comme dans le navigateur ou avec ping, ne fonctionnait, et je ne pouvais même pas atteindre le routeur.
    Dans les deux cas, il a suffi d’ouvrir une fois l’app Mullvad VPN pour que tout refonctionne. Je ne sais pas pourquoi le simple fait d’ouvrir l’app corrige le problème.

    • Une app VPN modifie la table de routage, donc le trafic était probablement routé vers une interface inexistante jusqu’à ce que vous lanciez l’app VPN.

  • Ce n’est pas tout à fait lié, mais il existe aussi un autre vieux bug : un bug vieux de 11 ans dans Popen() sur macOS : https://news.ycombinator.com/item?id=37238433

    • Si c’est votre bug, il vaut mieux envoyer aussi un Feedback avec un patch. Les projets open source côté Apple n’acceptent généralement pas les PR.

  • Pour info, j’avais des problèmes de connexion avec Mullvad.app, mais en lançant la configuration Mullvad WireGuard dans Wireguard.app, cela fonctionnait correctement.

  • J’ai récemment installé la dernière beta de Sonoma et je comprends maintenant pourquoi je n’arrivais pas à faire fonctionner Mullvad, quoi que je tente.
    Je suis soulagé que Mullvad travaille sur un contournement. Ce matin, j’envisageais même de revenir à Ventura ; j’ai maintenant l’impression que mon problème était bien celui-là.

    • Il n’est pas écrit qu’ils travaillent sur un contournement. Il est indiqué aux utilisateurs de ne pas passer à Sonoma tant qu’Apple n’a pas corrigé le bug.
    • La combinaison tailscale/mullvad devrait probablement encore fonctionner. Cela pourrait être un contournement acceptable jusqu’à ce qu’Apple corrige le problème.

  • Je suis content que Mullvad mette davantage de pression publique sur ce problème. Ce bug était clairement visible et assez préoccupant.

    • Était-il déjà connu ailleurs ? Mullvad semble l’avoir signalé après la 6e beta, et à ce stade on est assez proche d’une RC.
      Le texte original dit : « we have investigated this issue after the 6th beta was released and reported the bug to Apple ».

  • Dans mon cas, la solution a été de télécharger la configuration WireGuard et d’utiliser l’app Wireguard.

    • Mais l’app Wireguard ne risque-t-elle pas de laisser fuiter des données et d’être moins sûre que l’app Mullvad ?
    • Ce n’est une solution que si vous ne mettez pas de règles de pare-feu PostUp et PostDown dans la configuration WireGuard. Dans ce cas, difficile de vraiment appeler ça une solution.

  • Question : si pflog1 n’est pas créé, pf fonctionne-t-il comme prévu ?
    Si tcpdump n’enregistre rien sortant vers pflog1, cela semble indiquer que les données ne sont pas envoyées à pflog1. Cela voudrait dire que le problème se situe en amont.
    pflog1 était-elle connectée et active ? Autrefois, il fallait connecter et activer l’interface manuellement. MacOS le fait-il automatiquement ?
    Bien sûr, ce n’est pas au rapporteur du bug d’isoler cela. Mais à un moment donné, l’ingénieur chargé du dossier posera ce genre de questions, donc autant préparer les réponses.

    • Y a-t-il quelque chose qu’on pourrait ajouter à la procédure de reproduction comme contournement ? Par exemple, comme mentionné, connecter et activer l’interface après le chargement des pfrules.
    • Ensuite, pour supprimer l’interface supplémentaire, il faut aussi faire ceci :
      ifconfig pflog1 destroy