Résumé

  • Sharon Goldberg, Aanchal Malhotra, Isaac E. Cohen et Erik Brakke ont établi que d’anciens clients ntpd acceptaient un paquet Kiss-o’-Death sans vérifier que son horodatage d’origine correspondait à leur requête.
  • Un paquet usurpé par serveur configuré pouvait priver le client de toute correction pendant une durée choisie par l’attaquant ; la réponse durable consiste à rattacher le refus à l’échange et à plafonner le recul qu’il peut commander.

Un déni de service évoque volontiers une foule. Ici, il suffisait d’un messager. Il se présentait comme un serveur NTP débordé, délivrait un code RATE, puis laissait la victime exécuter elle-même la longue interruption : ne plus revenir avant l’expiration du délai indiqué.

C’est l’asymétrie mise au jour en 2015 par Aanchal Malhotra, Isaac E. Cohen, Erik Brakke et Sharon Goldberg. Leur cible n’était pas le calcul de l’heure en général, mais un chemin de contrôle précis dans ntpd. Une réponse négative conçue pour protéger les serveurs publics était traitée comme un ordre, alors que le client ne s’assurait pas qu’elle répondait à une question qu’il venait réellement de poser.

La politesse d’un serveur est une commande chez le client

Le paquet Kiss-o’-Death, ou KoD, est une réponse NTP particulière. Il utilise le mode 4, place l’indicateur de seconde intercalaire à 3 et la strate à 0, puis inscrit un code de quatre caractères dans le champ d’identification de référence. DENY et RSTR signifient que le service est refusé ; RATE demande d’espacer davantage les requêtes.

Cette faculté répond à un besoin légitime. Un serveur partagé doit pouvoir se protéger d’un client qui l’interroge trop souvent. Mais la protection du serveur crée un pouvoir sur le calendrier du client. Dès que ce dernier accepte le message, une entrée distante modifie toutes ses requêtes futures.

L’échange NTP ordinaire disposait pourtant déjà d’un reçu. La requête de mode 3 contient un horodatage de transmission. Dans la réponse de mode 4, le serveur le renvoie comme horodatage d’origine. Le test TEST2 peut alors vérifier que la réponse appartient à la requête en attente. Le mécanisme ressemble à un nonce : il ne prouve pas cryptographiquement l’identité du serveur, mais empêche une réponse inventée hors chemin de se greffer librement sur la conversation.

Les versions 4.2.6 et 4.2.8 testées par l’équipe n’appliquaient pas ce contrôle au KoD. Un attaquant capable d’usurper l’adresse IP du serveur pouvait donc produire une réponse dont l’horodatage d’origine était faux et voir le client lui obéir quand même.

Le coût se mesurait en serveurs, pas en secondes

Le champ de scrutation indique un intervalle par une puissance de deux. Une valeur de 17 représente au moins 2^17 secondes, soit environ trente-six heures. Les chercheurs ont constaté que le client acceptait aussi des valeurs supérieures à la plage attendue. Avec 25, l’ordre de grandeur devient une année.

L’attaquant devait connaître l’adresse du client et celle d’un serveur qu’il utilisait. Le document explique comment découvrir le serveur actif : envoyer au client une requête de mode 3 et examiner la réponse de mode 4. Chez un client IPv4 synchronisé, l’identifiant de référence pouvait révéler l’adresse du serveur courant.

Un faux KoD semblait ensuite provenir de ce serveur. Si le client basculait vers une autre source configurée, l’attaquant recommençait. Une instruction acceptée pour chaque source suffisait à vider l’ensemble des choix disponibles. La métrique pertinente n’était donc pas le nombre de paquets par seconde, mais le nombre de sources de temps que le client pouvait encore consulter.

Lors de l’expérience en laboratoire, ntpd 4.2.8p2 utilisait trois serveurs publics. En une heure et demie environ, l’équipe avait provoqué le troisième KoD. Elle a alors cessé l’expérience ; le client est néanmoins resté muet pendant les cinquante heures suivantes. Le délai minimal demandé était d’environ trente-six heures.

L’étude a aussi sondé l’Internet de 2015. Plus de treize millions d’adresses IPv4 répondaient au type de requête nécessaire à la première étape. Ce résultat ne décrit ni le parc actuel ni treize millions de vulnérabilités complètes : il fallait encore que le client réagisse au KoD et qu’un serveur synchronisé soit visible. Il mesure l’étendue historique d’une condition préalable.

Retirer la correction n’est pas choisir l’heure

Le KoD falsifié ne plaçait pas directement l’horloge sur une heure arbitraire. Il supprimait les futurs échantillons du serveur. La machine continuait alors sur sa propre base de temps, et sa dérive dépendait de l’oscillateur, de la virtualisation, de la charge et de l’implémentation.

Cette distinction limite les conclusions sans diminuer la gravité du mécanisme. Une machine physique stable peut tenir longtemps ; une machine virtuelle sollicitée peut accumuler plus vite de l’incertitude. Les journaux, les certificats, l’authentification, les bases distribuées et les tâches planifiées n’ont pas tous la même tolérance. Le paquet garantit le retrait de la correction, pas une erreur identique chez chaque victime.

Pour enquêter, il faut donc conserver la dernière synchronisation valide, le code KoD, le résultat de TEST2, la valeur demandée, la valeur finalement appliquée et l’évolution locale de l’incertitude. Une horloge fausse découverte des heures plus tard ne dit pas à elle seule quel message a fermé le robinet.

Une réparation en deux dimensions

L’avis du NTP Project sur le Bug 2901 indique que les versions antérieures à 4.2.8p4 étaient concernées par l’usurpation directe. La version p4 a rendu obligatoire la validation de l’horodatage d’origine pour le KoD. L’attaquant hors chemin ne pouvait plus inventer gratuitement une réponse acceptable.

Cette modification augmentait le coût, sans constituer une authentification cryptographique. Le papier décrit un reste, baptisé « priming pump » : envoyer au vrai serveur de nombreuses requêtes usurpant l’adresse de la victime, afin que le serveur lui-même produise un KoD correctement lié. Cette voie demande davantage de trafic et conduit souvent à un recul plus court, par exemple une valeur 10, proche de quinze minutes, plutôt qu’à une année choisie.

Le RFC 8633 a ensuite posé deux règles complémentaires. Un client ne doit accepter un KoD que si l’horodatage d’origine est valide. Même dans ce cas, il doit fixer une limite raisonnable au délai RATE, jamais au-delà de 13, c’est-à-dire deux heures. Une seule requête portant une valeur anormalement élevée peut d’ailleurs signaler une attaque.

Lier le message répond à la question « à quelle requête appartient-il ? ». Authentifier répond à « qui parle ? ». Plafonner répond à « combien de temps peut-il décider à ma place ? ». Une conception sûre ne transforme pas ces trois questions en une seule case à cocher.

Une recherche qui a traversé les couches

Le profil officiel de Goldberg à Boston University décrit une pratique mêlant cryptographie, théorie des jeux et algorithmes aux mesures, modèles et simulations de réseau. L’étude NTP suivait précisément ce trajet : le RFC donnait la sémantique attendue, les tests d’implémentation révélaient la branche réellement empruntée, l’expérience mesurait la durée de l’état installé, le sondage estimait les préconditions visibles.

Le travail appartient aux quatre auteurs. La page du projet date le début de la divulgation responsable du 20 août 2015. Network Time Foundation, NTPsec, Cisco et Red Hat ont publié des correctifs avant la divulgation du 21 octobre. Choisir Goldberg comme fil biographique ne doit pas convertir la recherche de Malhotra, Cohen et Brakke en invention solitaire.

La question de contrôle dépasse aujourd’hui NTP. Lorsqu’un système reçoit « réessayez plus tard », « refusez », « isolez » ou « arrêtez », quelle requête autorise l’ordre ? Quelle identité le porte ? Qui fixe sa durée ? Que voit l’opérateur pendant que le destinataire se tait ?

Une réponse négative n’est pas un simple échec. Elle gouverne l’avenir. Le KoD devenait dangereux parce qu’il était peu coûteux à falsifier et long à subir. Le principe inverse reste robuste : exiger un contexte, borner le retrait et journaliser l’instant où une horloge cesse de demander.

Sources