Deux lignes de code qu’Apple n’a jamais expliquées
En parcourant les en-têtes du SDK de macOS 26.4, on tombe sur une petite bizarrerie. Sept nouveaux événements du framework Endpoint Security ont fait leur apparition, tous nommés de façon aussi peu engageante que possible, ES_EVENT_TYPE_RESERVED_0 à ES_EVENT_TYPE_RESERVED_6.
Aucune description, aucun commentaire, contrairement à l’habitude d’Apple qui accompagne d’ordinaire chaque nouvel événement d’une brève explication dans le fichier d’en-tête.
C’est Patrick Wardle, fondateur de la fondation Objective-See, qui a remarqué l’anomalie fin mars et a décidé de la faire parler par la force, à coups de débogueur.
Le résultat dépasse la simple curiosité technique, deux de ces événements réservés permettent de construire un pare-feu réseau natif sans passer par le mécanisme habituel, lourd et contraignant, des Network Extensions.
Ce qu’Apple laisse filtrer, et ce qu’elle garde jalousement
Le fait que macOS embarque de nouveaux crochets réseau n’est en soi pas extraordinaire, Apple en ajoute régulièrement.
Ce qui l’est davantage, c’est qu’ici, contrairement à d’autres événements réservés découverts la même semaine par Wardle, celui-ci ne nécessite aucun privilège particulier. N’importe quel client Endpoint Security correctement signé peut s’y abonner et recevoir, en temps réel, chaque tentative de connexion sortante du système.
Ce détail d’apparence anodine dessine en creux la politique d’Apple sur ce que l’écosystème de sécurité tiers a le droit de voir. Un événement voisin, dédié cette fois à la surveillance du presse papiers pour la protection anti arnaque intégrée à Terminal, reste lui verrouillé derrière un entitlement privé, réservé aux seuls processus signés par Apple.
Deux événements nés la même semaine, dans le même fichier d’en-tête, mais traités de façon radicalement différente. La frontière entre ce qu’Apple partage et ce qu’elle protège n’est donc pas technique, elle est stratégique.
Dans les entrailles d’Endpoint Security
La méthode de Wardle est d’une simplicité trompeuse. Plutôt que d’analyser statiquement le code, il écrit un client Endpoint Security minimal, s’abonne à chacun des sept événements réservés, puis observe ce qui se passe réellement sur un Mac en fonctionnement normal.
Les identifiants 0, 1 et 2 refusent tout bonnement l’abonnement, sans doute des fonctionnalités pas encore activées. Les identifiants 3 à 6, en revanche, répondent présent. Les événements 153 et 154, en particulier, se déclenchent en paire à chaque connexion réseau, portés le plus souvent par mDNSResponder, le démon de résolution DNS de macOS, ou directement par le processus à l’origine de la connexion.
En imprimant les octets bruts du message et en les confiant à une intelligence artificielle pour reconstituer la structure sous-jacente, Wardle obtient un résultat cohérent, l’événement 153 est un événement d’autorisation, qui se déclenche avant qu’une connexion sortante ne soit établie et attend une réponse d’autoriser ou de refuser. L’événement 154 est son pendant informatif, déclenché une fois la connexion effectuée, enrichi du nom d’hôte demandé, de l’adresse IP résolue, et, fait notable, du chemin du processus réellement responsable de la requête quand celle-ci transite par un intermédiaire comme mDNSResponder ou le sous-système réseau de WebKit.
Concrètement, cela signifie qu’un logiciel de sécurité peut désormais intercepter, autoriser ou bloquer chaque connexion sortante d’un Mac sans installer la moindre extension réseau. Wardle l’a vérifié en conditions réelles en injectant ce mécanisme dans LuLu, son pare-feu open source. Sur macOS 26.4 et plus récent, quelques lignes suffisent à faire basculer entièrement la détection des connexions vers ce nouveau canal, sans toucher au reste de l’application. Le test fonctionne.
Cette avancée n’est pas sans limites. Le délai de réponse imposé pour les événements d’autorisation n’est que de quinze secondes, largement suffisant pour un outil de détection automatique, mais problématique pour un pare-feu qui attend une décision humaine. L’entitlement nécessaire, bien que standard, reste soumis à l’approbation d’Apple au cas par cas, contrairement aux Network Extensions dont les développeurs peuvent s’auto attribuer certains droits. Et surtout, tant que ces événements demeurent non documentés, Apple se réserve le droit de les modifier ou de les retirer sans préavis à la prochaine mise à jour.
Un autre détail éclaire le climat dans lequel s’inscrit cette découverte. Wardle avait précédemment signalé un bug plus préoccupant, une simple tentative d’abonnement à un événement situé au delà de la dernière valeur valide provoquait un arrêt brutal du noyau, accessible à n’importe quel processus disposant des droits nécessaires. Apple a corrigé ce problème dans la même version 26.4, signe que cette zone du système reçoit une attention particulière en ce moment, probablement parce qu’elle est en pleine réécriture.
Ce que cela signifie pour les prochains mois
Pour l’utilisateur final, ce changement reste invisible, aucune interface, aucun réglage à modifier.
Pour les éditeurs d’outils de sécurité Mac en revanche, la porte qui vient de s’entrouvrir change le calcul économique et technique de leurs produits. Construire un pare-feu ou un outil de détection réseau via une Network Extension impose une charge de développement et de certification significative. Un simple client Endpoint Security, lui, se déploie plus vite et s’intègre plus facilement dans une suite de sécurité existante.
Il serait toutefois imprudent pour un administrateur de parc Mac de déployer dès maintenant un outil professionnel reposant sur ce mécanisme. Rien ne garantit qu’Apple ne le documente pas officiellement dans les prochains mois, ce qui serait la suite logique si l’entreprise souhaite réellement simplifier la vie des éditeurs tiers, ni qu’elle ne referme cette porte au contraire, comme elle l’a fait pour l’événement de surveillance du presse papiers, dès qu’un usage massif par des outils commerciaux se fera sentir.
Le signal le plus probable, au vu de la trajectoire observée depuis plusieurs mois sur XProtect et sur la refonte plus large de l’architecture de sécurité d’Apple Silicon, est une clarification progressive d’ici la fin de l’année, sans doute à l’occasion d’une mise à jour mineure plutôt que d’une keynote. D’ici là, les responsables sécurité qui gèrent des flottes de Mac ont intérêt à surveiller de près les notes de version de chaque mise à jour 26.x, ces événements réservés étant précisément le genre de détail qu’Apple ne prend pas la peine d’annoncer.
Sources
| Titre | URL | Auteur original | Date |
|---|---|---|---|
| Building a Firewall …via Endpoint Security!? Reverse Engineering macOS 26.4’s Undocumented Network Events | https://objective-see.org/blog/blog_0x86.html | Patrick Wardle, Objective-See Foundation | 26 mars 2026 |
| No Paste for You! Reverse Engineering Apple’s ClickFix Protections | https://objective-see.org/blog/blog_0x87.html | Patrick Wardle, Objective-See Foundation | 31 mars 2026 |
Vous avez une question, une idée ou une remarque ? Je serai ravi de vous lire ! ✉️ henrido@hdrapin.com
En savoir plus sur Les miscellanées Numériques
Subscribe to get the latest posts sent to your email.