Résumé

  • La RFC 3128 combina deux techniques déjà connues, le fragment minuscule et le chevauchement, afin de produire un en-tête TCP final différent de celui que le filtre avait examiné.
  • La correction exigeait qu’un fragment TCP d’offset zéro contienne l’en-tête minimal complet nécessaire à la décision, tout en continuant à rejeter l’offset un.
  • L’effet dépendait de la politique de filtrage et de l’algorithme de réassemblage ; le passage des fragments ne prouvait ni connexion établie, ni compromission, ni vulnérabilité universelle.

Imaginons un poste de contrôle qui vérifie un passeport correct, puis laisse un autre service recomposer le visage du voyageur à partir de plusieurs photographies dont certaines se recouvrent. Le problème n’est pas que le contrôle n’a rien regardé. Il a regardé un objet qui ne demeurait pas stable.

C’est la situation que la RFC 3128 rendit précise en juin 2001. Le premier fragment IPv4 commençait à l’offset zéro et transportait suffisamment d’octets de l’en-tête TCP. Son port de destination désignait un service autorisé à recevoir une connexion entrante. Les indicateurs nécessaires paraissaient réguliers. Le filtre pouvait donc l’admettre selon la politique qu’il connaissait.

Un deuxième fragment commençait lui aussi à l’offset zéro, mais ne contenait que huit octets de transport. Cette courte tranche couvrait les ports source et destination ainsi que le numéro de séquence, sans inclure les indicateurs TCP placés plus loin. Elle pouvait remplacer le port de destination par celui d’un service qui n’aurait pas dû accepter une connexion entrante. Un troisième fragment achevait le datagramme.

Si la pile destinataire donnait priorité aux octets du court chevauchement, le segment réassemblé associait le nouveau port aux indicateurs restés dans la première représentation. Le filtre avait autorisé une connexion vers un service ; l’hôte pouvait recevoir un en-tête visant un autre service.

La RFC 3128 ne partait pas de rien. La RFC 1858 avait séparé deux attaques. Dans l’attaque du fragment minuscule, la fragmentation dissimulait une partie des champs TCP indispensables à la politique. Dans l’attaque par chevauchement, des octets répétés permettaient à deux systèmes de ne pas choisir la même version lors du réassemblage. Sa « méthode indirecte » proposait notamment de bloquer les fragments TCP dont l’offset valait un.

Ce nombre était important. L’offset IPv4 est exprimé par blocs de huit octets. Un fragment à l’offset un commence juste après les huit premiers octets TCP ; le rejeter empêchait une manière classique de séparer les indicateurs de contrôle du début de l’en-tête. La règle semblait garantir que le premier fragment exposerait les informations essentielles.

La combinaison décrite six ans plus tard contourna cette intuition. Le fragment de remplacement ne commençait pas à un. Il recommençait à zéro. La défense dirigée contre une séparation visible ne répondait pas à une nouvelle version des mêmes premiers octets.

Cette histoire est aussi celle d’une autorité partagée. L’émetteur choisissait les limites, les offsets et le contenu répété. Le filtre décidait à partir de la vue disponible au périmètre. La pile IP de destination décidait quels octets survivraient au chevauchement. TCP décidait si le segment reconstruit était acceptable. Enfin, le service visé décidait si une action applicative suivrait. Confondre ces décisions aurait transformé une possibilité de contournement en récit exagéré de compromission.

Le texte resta donc prudent. Le résultat dépendait « de la mise en œuvre précise » du réassemblage. Les premiers RFC d’IPv4 autorisaient l’arrivée désordonnée et imposaient aux récepteurs de réunir les fragments, mais ils n’avaient pas créé un arbitre universel pour chaque octet qui se répétait. La RFC 815 expliquait comment gérer trous et chevauchements dans un algorithme pratique ; elle illustrait justement que le réassemblage était une opération locale, pas une vérité observée par tous les équipements du chemin.

La correction de la RFC 3128 tenait en une nouvelle condition. Pour TCP, si l’offset vaut zéro et si la longueur de transport est inférieure à la taille minimale d’un en-tête complet, le filtre doit abandonner le paquet. La règle sur l’offset un reste en place. L’équipement n’accorde ainsi plus une autorisation fondée sur un fragment initial trop court pour stabiliser tous les champs qui justifient la décision.

Cette correction ne promettait pas de supprimer toute ambiguïté IPv4. Elle ne disait pas que chaque pare-feu devait réassembler tous les datagrammes. Elle ne normalisait pas rétroactivement toutes les piles. Elle fixait une exigence plus modeste et plus vérifiable : une décision sur les ports et les indicateurs TCP ne peut reposer sur un premier fragment qui ne les contient pas entièrement.

La suite de l’histoire confirme la portée du problème sans prouver une adoption particulière. La RFC 6274 revint sur les risques de sécurité d’IPv4. Pour IPv6, la RFC 5722 exigea l’abandon de tout datagramme contenant des fragments qui se chevauchent. La RFC 7112 exigea que le premier fragment IPv6 porte toute la chaîne d’en-têtes. La RFC 8900 décrivit plus largement la fragilité opérationnelle de la fragmentation au milieu d’équipements qui n’offrent pas tous les mêmes garanties.

Ces textes ultérieurs ne permettent pas d’affirmer que tous les pare-feu de 2001 furent vulnérables. Ils montrent autre chose : lorsqu’un système d’application de la politique et un système de consommation n’interprètent pas le même objet, les règles peuvent être exactes localement et fausses à l’échelle du trajet.

Ce principe dépasse les fragments IP. Un proxy et un serveur peuvent normaliser une URL différemment. Un filtre peut décoder une chaîne une fois alors qu’une application la décode deux fois. Une passerelle peut valider un schéma puis transmettre une forme que le service reconstruit autrement. Dans chaque cas, le contrôle porte sur une représentation intermédiaire dont les champs décisifs peuvent encore changer.

La RFC 3128 mérite donc sa place dans l’histoire de l’Internet non pour avoir annoncé une catastrophe universelle, mais pour avoir posé une question de preuve. Le journal du filtre démontre qu’un ensemble d’octets visibles satisfaisait une règle. Il ne démontre pas, à lui seul, quel en-tête l’hôte a finalement remis à TCP. Entre admission et effet, il reste une chaîne qu’il faut observer.

Sources