- Mullvad indique qu’une fuite de trafic juste après une mise à jour système peut se produire sur macOS, et que la seule solution confirmée à ce jour est de redémarrer
- Dans cette situation, le pare-feu macOS ne semble pas fonctionner correctement, si bien que les règles de pare-feu configurées sont ignorées
- La majeure partie du trafic passe par le tunnel VPN en raison de la table de routage, mais les applications ne sont pas toujours conçues pour suivre cette table
- De macOS 14.6 jusqu’à la bêta la plus récente de 15.1, certaines apps et certains services Apple peuvent envoyer du trafic en dehors du tunnel
- Mullvad a signalé le problème à Apple et continue d’étudier les contournements possibles au niveau de l’application
Conditions de fuite observées après une mise à jour
- Une fuite de trafic peut se produire après une mise à jour système de macOS
- D’après ce que Mullvad a pu constater jusqu’à présent, le problème est résolu par un redémarrage
- Dans cet état, le pare-feu macOS ne fonctionne pas normalement et semble ignorer les règles de pare-feu configurées
- En raison de la configuration de la table de routage, la plupart du trafic entre dans le tunnel VPN
- Cependant, les applications ne sont pas obligées de suivre la table de routage, et peuvent donc, si elles le veulent, envoyer du trafic en dehors du tunnel VPN
- Les apps et services d’Apple eux-mêmes font partie des exemples concernés
- La plage concernée va de macOS 14.6 jusqu’à la bêta la plus récente de 15.1
- Mullvad a signalé ce problème à Apple et continue de fournir des informations complémentaires et d’étudier les contournements possibles dans l’application
Comment vérifier si vous êtes concerné
- Ajouter dans le terminal une règle de pare-feu qui bloque tout le trafic
echo "block drop quick all" | sudo pfctl -ef -
- Vérifier si du trafic est envoyé en dehors du tunnel VPN
curl https://am.i.mullvad.net/connected
- Après le test, désactiver le pare-feu et supprimer toutes les règles
sudo pfctl -d
sudo pfctl -f /etc/pf.conf
- Il est également possible de vérifier la fuite dans l’app Mullvad
- Vérifier que vous n’êtes pas connecté au VPN
- Vérifier l’interface par défaut
route get mullvad.net | sed -nE 's/.*interface: //p'
- Se connecter à un serveur VPN avec l’app Mullvad
- Dans la commande ci-dessous, remplacer
<interface> par l’interface identifiée à l’étape précédente
curl --interface <interface> https://am.i.mullvad.net/connected
- En fonctionnement normal, la réponse doit indiquer que vous êtes connecté à Mullvad ou qu’il est impossible de se connecter au serveur
- Si la réponse indique que vous n’êtes pas connecté à Mullvad, cela signifie qu’il y a une fuite de trafic
1 commentaires
Avis sur Hacker News
À chaque mise à jour de macOS, certains réglages système revenaient à leurs valeurs par défaut, notamment le pare-feu, et il fallait à chaque fois les reconfigurer un par un.
Après avoir constaté plusieurs fois que l’installation ou la mise à jour de macOS ou d’iOS prenait plus de temps quand l’appareil était connecté à Internet, j’éteins désormais le routeur pendant les mises à jour.
Avec l’intégration continue de fonctions d’IA dans Windows, macOS, Android, etc., j’ai l’impression que même pendant les mises à jour, les uploads de données personnelles ou les téléchargements de données côté serveur vont encore augmenter sous prétexte de « préparer » de nouvelles fonctions d’IA.
Sans Internet, l’installateur n’a pas d’autre choix que de repousser ce processus à plus tard, ce qui laisse un peu de temps après le démarrage pour modifier les réglages par défaut.
Il y a d’autres discussions à ce sujet sur https://news.ycombinator.com/item?id=26418809 et https://news.ycombinator.com/item?id=26303946.
Depuis des années, les mises à jour automatiques échouent constamment avec des erreurs du type « échec de la personnalisation du logiciel, vérifiez votre connexion Internet ». Et ce alors même qu’Internet fonctionne parfaitement ; pour mettre à jour, il fallait finalement une clé USB live et une connexion Ethernet.
De ce point de vue, seul Linux était relativement « propre », mais aujourd’hui certaines distributions commencent elles aussi à glisser discrètement des éléments à caractère spyware. L’enshittification des systèmes d’exploitation continue.
Apple veut que ses clients utilisent certaines fonctions, alors on dirait qu’ils les activent tout simplement pendant la mise à niveau, et c’est assez déplaisant.
Si l’on veut un VPN sans fuite, il faut l’implémenter au niveau du routeur, pas à l’intérieur de l’appareil. C’est vrai pour n’importe quel appareil, mais encore plus pour les appareils Apple.
Je recommande vivement de capturer le trafic sur le segment filaire et de l’envoyer dans Wireshark. C’est possible avec un routeur ou un tap Ethernet passif, et vous verrez pas mal de paquets partir ailleurs que vers le point d’entrée du VPN.
Avec un routeur, on peut aussi vérifier les fuites depuis le téléphone. Si les appels Wi-Fi sont activés, on découvre aussi que le téléphone établit toutes les 30 secondes une connexion TCP vers le serveur de contrôle de l’opérateur.
Par exemple, si vous utilisez T-Mobile et que vous êtes à l’étranger, même sans utiliser cette SIM comme SIM principale, l’opérateur obtient les logs de toutes les IP de sortie que vous utilisez.
Le fait qu’Apple semble prendre en charge les extensions VPN et de filtrage réseau tient presque du leurre : ils les désactivent volontiers pour leur propre trafic.
Sur iOS, l’App Store contourne le VPN, et si vous utilisez un VPN, Apple peut même bloquer le téléchargement des mises à jour. Je l’ai découvert en faisant passer le VPN par le routeur, quand le téléchargement d’une mise à jour a échoué.
Sur Mac, le problème est particulièrement visible au premier démarrage. On a l’impression que le Mac refuse d’établir le VPN tant qu’il ne s’est pas connecté une fois en dehors du VPN.
Après une sortie de veille, il m’arrive souvent qu’un tunnel WireGuard à la demande utilisant Cloudflare Warp n’arrive plus à envoyer de paquets. Si je débranche l’Ethernet, désactive le mode toujours actif, attends environ 30 secondes, puis le réactive et rebranche l’Ethernet, la connexion revient.
Cela dit, je ne suis pas encore certain qu’il n’y ait réellement aucune fuite pendant ce processus, donc il faut que j’enquête davantage.
Il arrive aussi que l’audio d’un onglet fuie avant même la connexion.
Même avec toutes les fonctions de « restauration » désactivées, macOS « lançait » le navigateur après un redémarrage, avant la connexion, et du contenu qui était en pause avant le redémarrage, ou même plusieurs jours auparavant, se mettait parfois à jouer automatiquement.
Depuis, j’ai désactivé cette fonction assez en profondeur, mais je ne lui fais plus jamais confiance.
À long terme, ils transformeront cette faveur en crédit pour encaisser les critiques du type « Safari est nul », puis Apple et Google finiront par pousser Internet vers une guerre où les navigateurs deviennent des boutiques d’applications.
Les deux entreprises y gagnent, peuvent se rejeter la faute, et peuvent encourager des comportements anticoncurrentiels tout en donnant l’impression que les intérêts de leurs organisations respectives se trouvent simplement alignés par hasard.
Internet a été capturé, gamifié, marchandisé et intégré verticalement par une poignée de géants.
Les appareils mobiles sont en pratique des dispositifs de pistage addictifs, et les gouvernements sont tellement intéressés par l’usage de ces outils séduisants pour les fonctions administratives qu’ils ne voient pas le danger de laisser en place des points où le droit, la technologie et le business s’emboîtent pour permettre des abus systémiques.
Comment sait-il qui est l’utilisateur, et comment sait-il quelles apps ouvrir ? Si c’est avant la connexion, je soupçonne qu’en réalité il vous connecte automatiquement, mais ne l’affiche simplement pas à l’écran.
Cela ressemble à un assez gros bug de sécurité, et il est étrange que ce ne soit pas exploité.
Cela me rappelle l’époque où, lorsqu’un appel FaceTime arrivait, l’iPhone activait la caméra et envoyait la vidéo à l’appelant même si l’on ne répondait pas.
Jusqu’à ce que l’on saisisse le mot de passe après un redémarrage, les données utilisateur sont chiffrées, donc le système ne devrait rien savoir de l’utilisateur.
Il ne devrait donc pas non plus savoir quelles apps étaient ouvertes avant le redémarrage, et encore moins être capable de jouer du son.
Quand on ouvre le navigateur, la dernière page ouverte apparaît brièvement, même lorsqu’on avait pris soin de la fermer avant de quitter le navigateur.
Cela n’a jamais entraîné de gros problème pour moi, mais c’est très agaçant, et selon le contexte cela pourrait devenir un vrai problème.
La date de l’article est indiquée comme aujourd’hui, mais j’ai l’impression d’avoir lu exactement le même texte il y a environ un mois
https://mullvad.net/en/blog/bug-in-macos-14-sonoma-prevents-...
Cela semble avoir été corrigé le 22 septembre 2023 : https://mullvad.net/en/blog/macos-14-sonoma-firewall-bug-fix...
Les équipes produit et ingénierie d’Apple ne semblent pas accorder à la vie privée des utilisateurs autant d’importance que son département marketing
J’avais entendu dire que NixOS était bien, mais je pensais avoir encore besoin d’un système d’exploitation graphique à cause du navigateur et des apps que j’utilise souvent
J’ai envie de sortir de l’écosystème macOS, mais les choses vont de plus en plus dans la mauvaise direction. J’ai l’impression d’avoir organisé toute ma vie numérique autour d’Apple
Le fait que « les apps n’aient pas besoin de respecter la table de routage » est délirant
Si ce n’est qu’une fiction indicative, je ne comprends pas pourquoi on crée une table de routage et pourquoi on l’expose à l’utilisateur
Les fournisseurs devraient arrêter de s’accorder des privilèges sur les appareils des utilisateurs
Le premier démarrage juste après une mise à jour système de macOS est truffé de bugs depuis très longtemps
Il lance plein d’apps qui n’étaient même pas ouvertes avant la mise à jour, généralement celles qui ressemblent aux 5 à 10 dernières apps fermées récemment
C’étaient des apps complètement fermées, et le réglage « reprendre » était aussi désactivé. Ce n’est pas une simple reprise : le système lance les apps comme pour leur demander de créer une nouvelle fenêtre, et il le fait avant la fin du montage des disques
Du coup, à chaque mise à jour, les apps que j’utilise souvent apparaissent soudainement et me disent que leurs réglages et leurs données ont disparu
Après un nouveau redémarrage, tout redevient normal, donc ce n’est pas un énorme problème, mais ça donne une impression de négligence et rend l’OS instable
Le problème de pare-feu n’a peut-être rien à voir avec ça, mais il faudra voir si cette affaire pousse Apple à corriger aussi ce bug
C’est agaçant, parce que le Mac finit trop souvent par tout rouvrir quand même. Quand on cherche comment l’empêcher, la réponse est toujours « désactivez ce réglage », celui-là même que j’ai déjà désactivé