Résumé

  • RFC 3397 attribua le code DHCP 119 à une liste ordonnée de domaines de recherche. Le client devait d’abord réunir les fragments selon RFC 3396, puis interpréter les pointeurs de compression RFC 1035 dans le bloc complet.
  • Cette politique précédait DNSSEC : un suffixe hostile mais accepté pouvait produire un autre nom pleinement qualifié dont la réponse, publiée par le domaine adverse, était néanmoins authentique et correctement signée.

Le mot saisi n’était pas toujours le nom interrogé. Entre myhost dans une application et une question DNS se trouvait une opération discrète : choisir un suffixe, fabriquer un FQDN, puis seulement demander son adresse. RFC 3397 normalisa la manière dont DHCP proposait ce choix à une machine.

Publié en novembre 2002 sur la voie de normalisation, le texte définit l’option DHCP Domain Search, numéro 119. Son périmètre était volontairement étroit. Elle configurait les domaines que le résolveur DNS devait essayer pour un nom incomplet. Elle ne décidait pas quel service de nommage utiliser ; RFC 2937 traitait cette autre question. Confondre les deux reviendrait à attribuer au format une autorité qu’il n’avait pas.

La liste n’était pas une suite de chaînes ordinaires. Le Searchstring enchaînait des noms codés sous forme d’étiquettes DNS et autorisait la compression de RFC 1035. Lorsqu’un suffixe avait déjà été écrit, le suivant pouvait le réutiliser au moyen d’un pointeur de deux octets. Dans un espace DHCP limité, éviter de répéter apple.com. avait une utilité concrète.

Mais le pointeur ne visait ni Internet ni un autre message. Son déplacement était compté depuis le début des données de l’option 119, sans inclure les octets du code et de la longueur. Il appartenait à un espace d’adressage local construit par le décodeur.

Cet espace pouvait être réparti dans plusieurs occurrences physiques. RFC 3397 s’appuyait sur RFC 3396 : le récepteur devait concaténer les parties de données avant de leur donner un sens. Les pointeurs de compression s’appliquaient ensuite à l’agrégat entier. Une cible pouvait donc se trouver de l’autre côté d’une coupure entre deux options 119 ; la coupure n’avait aucune valeur sémantique.

L’exemple du document assemble eng.apple.com. et marketing.apple.com. sur trois occurrences. Le second nom se termine par C004, qui renvoie au déplacement quatre de l’agrégat, là où commence apple.com.. Lire chaque occurrence comme une petite liste autonome rendrait ce pointeur faux. L’ordre des opérations faisait partie du protocole : concaténer, décompresser, puis interpréter la liste.

Une règle de fin empêchait le logiciel de compléter ce qu’il croyait reconnaître. Chaque domaine devait aboutir à l’étiquette racine de longueur zéro ou à un pointeur valide de deux octets. Si les données se terminaient au milieu d’un nom, la portion inachevée devait être rejetée. Les étiquettes déjà reçues ne constituaient pas une preuve du suffixe manquant.

La liste décodée gouvernait ensuite la construction de la question. RFC 3397 reprenait des recommandations de sécurité issues de RFC 1535 et RFC 1536 : les listes de recherche devaient être explicites plutôt que déduites du nom de la machine. Un nom contenant un point devait d’abord être essayé comme nom pleinement qualifié ; après échec seulement, les suffixes locaux pouvaient être ajoutés. Un nom sans point pouvait être suffixé immédiatement.

C’est à cette étape que se trouvait le risque principal. Un utilisateur pensait peut-être que myhost deviendrait myhost.bigco.com. Un serveur DHCP malveillant pouvait installer roguedomain.com, et le client demander alors myhost.roguedomain.com. Rien n’avait encore été falsifié dans DNS : la question elle-même avait été déplacée.

RFC 3397 précisait que DNSSEC n’empêchait pas cette attaque. L’opérateur de roguedomain.com pouvait publier et signer légitimement ses propres enregistrements. La validation attestait que la réponse correspondait bien au nom interrogé et n’avait pas été altérée. Elle ne disait pas pourquoi ce nom avait été produit ni s’il correspondait à l’intention humaine.

Dire que DNSSEC avait échoué masquerait donc le mécanisme. Plusieurs autorités successives étaient en jeu. La politique locale déterminait si DHCP pouvait remplacer une configuration manuelle. DHCP fournissait la liste. Le client acceptait et décodait l’option. Le résolveur choisissait un candidat. DNS répondait. DNSSEC authentifiait cette réponse. Enfin, l’application ouvrait éventuellement une connexion.

L’attaque par suffixe pouvait être plus efficace que l’annonce d’un faux serveur DNS. Elle utilisait l’infrastructure autoritative normale du domaine adverse ; aucune réponse forgée ni résolveur manifestement suspect n’était nécessaire. Un voyant de validation pouvait rester vert alors que le changement décisif s’était produit en amont.

Les mesures proposées correspondaient à cette séparation. Appliquer le comportement de recherche de RFC 1536, ne pas écraser par DHCP des paramètres DNS configurés manuellement et, si nécessaire, exiger l’authentification DHCP avant d’accepter l’option 119. Aucune mesure ne transformait cependant une preuve de provenance du message en preuve d’intention de l’utilisateur.

Pour l’exploitation, il faut conserver une chaîne de reçus. Le texte court d’origine, les listes manuelle et apprise, leur priorité, l’identité du serveur, la décision d’authentification, les fragments bruts, l’agrégat RFC 3396, les pointeurs suivis, les noms rejetés, l’ordre des candidats et la question effectivement émise doivent rester distinguables. Ensuite viennent la réponse, le résultat DNSSEC, l’adresse et la destination applicative.

Une capture qui contient l’option ne prouve pas son acceptation. Une liste correctement décodée ne prouve pas son utilisation. Une requête ne restitue pas forcément le texte saisi. Une signature valide ne révèle pas la politique de suffixe. En effaçant l’une de ces transitions, l’observateur transforme une histoire d’autorité en simple réussite de résolution.

Le registre IANA des paramètres BOOTP/DHCP confirme l’attribution du code 119, pas son déploiement. La recherche actuelle du RFC Editor ne signale aucun erratum correspondant à RFC 3397, sans certifier pour autant les décodeurs, la priorité des réglages ou le comportement des résolveurs.

Le principe de spécification initiale minimale de Lu Heng éclaire cette sobriété. Le RFC fixa ce qui devait être commun entre implémentations : la portée DNS, le codage, l’espace des pointeurs et la terminaison. Il ne dicta pas l’architecture interne de chaque système. La primauté du code en fonctionnement impose alors un contrôle concret : fragment traversé par un pointeur, suffixes réellement essayés et paquet DNS observé.

RFC 3397 montre ainsi qu’une réponse peut être vraie sans répondre à l’intention. La cryptographie authentifie un objet déjà nommé. Pour comprendre la destination, il faut aussi conserver la provenance de l’acte qui lui donna ce nom.

Sources