macOS frappé par une bombe à retardement de 49,7 jours dans sa pile réseau

L’équipe Photon a identifié un problème aux allures anachroniques sur son parc de Macs utilisés pour surveiller les services iMessage. Contrairement à un usage classique, ces machines fonctionnent en continu, sans redémarrage régulier. Dans ce contexte, le 30 mars, plusieurs systèmes ont soudainement cessé d’établir de nouvelles connexions réseau, sans alerte préalable, tout en restant joignables via ping, donnant l’illusion d’un fonctionnement intact.

Image tirée du film Speed (l'histoire d'un bus qui ne doit pas descendre sous les 50 miles/h sans quoi la bombe greffée sous son châssis explose !)

9 jours, 17 heures, 2 minutes et 47 secondes

Le billet explique que les sessions réseau actives restaient opérationnelles, compliquant fortement l’analyse : la panne se manifestait sans symptômes évidents et sans signal clair côté système. Heureusement un indice a mis la puce à l’oreille de l’équipe : la durée d’incubation du mal, à savoir 49,7 jours de fonctionnement — 49 jours, 17 heures, 2 minutes et 47 secondes, précisément.

Les chercheurs ont isolé un élément du sous-système réseau, le compteur tcp_now. Celui-ci mesure le temps écoulé depuis le démarrage à la milliseconde près. Implémenté comme un entier non signé sur 32 bits, il atteint une limite de 4 294 967 295 (2³² − 1), soit environ 49,7 jours, avant débordement.

En théorie, les connexions TCP expirées sont purgées après un court délai, de l’ordre de 30 secondes sous macOS. Mais lorsque tcp_now atteint sa limite et se retrouve figé à cause d’un bug dans le noyau XNU, les calculs d’expiration reposent sur une valeur constante. Les comparaisons temporelles deviennent incohérentes en 32 bits, si bien que les vérifications successives ne déclenchent plus la suppression des connexions, empêchant les mécanismes de purge de fonctionner. Les connexions inactives s’accumulent alors indéfiniment, jusqu’à saturation du pool de ports éphémères. Une fois cette limite atteinte, le système ne peut plus établir de nouvelles connexions et ses capacités réseau se dégradent rapidement. Le phénomène dépend fortement du niveau d’activité, mais dans un contexte serveur ou professionnel, la saturation peut intervenir en un temps relativement court.

La source note que la RFC 7323 définit pourtant le comportement attendu du timestamp TCP. Sa section 5.4 précise qu’un horodatage sur 32 bits avec une granularité de 1 ms voit son bit de signe basculer après environ 24,8 jours, et que les implémentations PAWS doivent invalider les timestamps après une période d’inactivité supérieure à 24 jours. Le noyau XNU ne respecte pas pleinement ces recommandations, ce qui introduit une divergence à l’origine de ce type d’anomalie.

Selon l’équipe Photon, la solution actuelle se résume à un redémarrage, même si une alternative est en cours de développement. Ils ont également identifié ce bug comme étant à l’origine de plusieurs problèmes évoqués en ligne sur les forums Apple Community.

L’auteur du rapport souligne que ce type de bogue appartient à une famille bien connue liée aux débordements d’entiers. Il explique qu’en C, un uint32_t peut représenter des valeurs de 0 à 4 294 967 295, au-delà desquelles il revient à zéro, en principe sans erreur ni exception. Il fait l’analogie avec un compteur kilométrique qui passerait de 999 999 à 000 000. Ce comportement est normal, mais devient problématique lorsque le code suppose une croissance monotone sans tenir compte du débordement

Il cite plusieurs exemples célèbres : le crash à 49,7 jours de Windows 95/98 ; le rollover de la semaine GPS, dont le compteur de semaines sur 10 bits déborde tous les 1 024 semaines (environ 19,7 ans), entraînant des dates incorrectes sur certains récepteurs ; le niveau 256 de Pac-Man troublé par le débordement d’entier sur 8 bits ; le « problème de l’an 2038 (Y2K38) » qui affectera les systèmes Unix qui stockent le temps sous forme d’un entier signé sur 32 bits (secondes depuis 1970) et qui dépasseront donc leur limite le 19 janvier 2038.