Conseil

IPv6 : analyser le risque des extensions d’en-têtes de paquets

L’expert Fernando Gont explique pourquoi les extensions d’entêtes de paquets IPv6 peuvent mettre en défaut des contrôles de sécurité ou créer les conditions d’un déni de service.

Fernando Gont
par
Publié le: 22 déc. 2014

Les paquets IPv4 souffrent de deux limitations en matière d’extensibilité. Tout d’abord, IPv4 n’offre que peu d’espace de données optionnelles – un maximum de 40 octets. La structure des paquets limite ainsi par construction le nombre et le type d’extensions pouvant être implémentées. En outre, toutes les options d’IPv4 – qu’elles soient destinées aux routeurs ou aux hôtes – partagent le même conteneur : chaque routeur transmettant un paquet IPv4 doit en traiter toutes les extensions, juste au cas où l’une d’entre elles serait pour lui.

Les paquets IPv6 offrent une structure considérablement différente. Les options IPv6 sont véhiculées par des en-têtes d’extension, et non pas dans l’en-tête de base, obligatoire, dont la taille est fixe. Les en-têtes d’extension sont insérés entre l’en-tête de base et l’en-tête du protocole de couche supérieure. La figure ci-dessous représente la structure d’un paquet IPv6 avec deux en-têtes d’extension.

 

Les paquets IPv6 suivent ainsi une structure comparable à une chaîne, dans laquelle chaque en-tête d’extension IPv6 indique le type d’en-tête qui suit, et sa propre longueur (à moins qu’elle n’ait une longueur fixe prédéfinie). Ainsi, il est possible de parcourir toute la chaîne d’en-tête IPv6 en partant de la première, obligatoire, jusqu’à la dernière des extensions. Certaines extensions courantes sont prédéfinies par des standards : les en-têtes d’extension pour l’encapsulation IPv4 sont ainsi décrits par le standard RFC2003.

Les options sont véhiculées dans différents types d’en-têtes d’extension IPv6, suivant le type de nœud auquel elles sont destinées. Par exemple, les options censées être traitées par tous les nœuds traversés au fil du transit jusqu’à la destination sont incluses dans l’entête d’extension Hop-by-Hop Options. Celles qui ne concernent que le destinataire sont véhiculées dans l’en-tête d’extension Destination Options. D’autres en-têtes d’extension peuvent avoir d’autres fonctions. Par exemple, le Routing Header doit permettre d’affecter la manière dont un paquet est transmis vers le nœud de destination, et le Fragment Header est conçu pour affecter le mécanisme de fragmentation/réassemblage des données.

Certains en-têtes d’extension doivent suivre un ordre prévis. Par exemple, si l’en-tête Hop-by-Hop Options est présent, il doit apparaître en première position après l’en-tête obligatoire. L’idée est ici simple : un en-tête d’extension censé être traité par tous les nœuds rencontrés doit arriver avant, dans la chaîne d’en-têtes, celui ne concernant que la destination. Ainsi, un routeur IPv6 n’a pas besoin de traiter toute la chaîne d’en-têtes. De quoi éviter le gaspillage de ressources de calcul au niveau du routeur, et optimiser le trafic.

Avec IPv6, les champs d’en-tête liés à la fragmentation ont quitté l’entête obligatoire pour être placés dans le Fragment Header, optionnel. Le concept est ainsi le suivant : le nœud émetteur construit toujours un paquet non fragmenté ; la fragmentation ne survient qu’après, si elle s’avère nécessaire.

 

Le paquet original est composé d’une partie non fragmentable, et une partie fragmentable (voire graphique ci-dessus). La partie non fragmentable consiste en l’en-tête et ses extensions devant être traités par tous les nœuds jusqu’à la destination. La partie fragmentable contient le reste du paquet, à savoir tous les en-têtes d’extension ne concernant que le nœud de destination, ainsi que l’en-tête du protocole de couche supérieure et les données. La partie non fragmentable sera également présente dans tous les fragments, tandis que la partie fragmentable sera découpée en plusieurs fragments.

 

Trouver l’information du protocole de la couche supérieure

Chaque routeur ou chaque élément intermédiaire, requis pour faire appliquer une liste de contrôle d’accès simple sur les paquets IP, doit pouvoir trouver l’en-tête du protocole de couche supérieure qui contient généralement les numéros de ports de source et de destination. La structure des paquets IPv4 simplifie la découverte par les nœuds de l’en-tête du protocole de couche supérieure : le nœud de traitement peut simplement « passer » l’espace d’options dont la taille est indiquée dans le champ « Internet Header Length » de l’en-tête IPv4.

Dans le cas d’IPv6, en revanche, rien ne pointe directement vers l’entreprise du protocole de couche supérieure. Dès lors, il faut parcourir l’ensemble des en-têtes d’extension pour arriver jusqu’à lui.

Jusqu’à récemment, le processus était encore plus compliqué : la chaîne d’en-têtes IPv6 pouvait être fragmentée, les en-têtes d’extension et l’en-tête du protocole de couche supérieure étant divisé sur plusieurs fragments. Par exemple, le paquet représenté ci-dessous fut un temps considéré comme valide.

 

Heureusement, le RFC7112, publié début 2014, a déclaré de tels paquets comme erronés : ils peuvent être ignorés.

Les implications de sécurité des en-têtes d’extension

Les implications de sécurité des en-têtes d’extension d’IPv6 peuvent être généralement répartis en quatre catégories : contournement des contrôles de sécurité ; conditions de déni de service en raison des besoins de traitement ; conditions de déni de service en raison des erreurs d’implémentation ; problèmes spécifiques à chaque en-tête d’extension.

Comme vu précédemment, trouver l’en-tête du protocole de couche supérieure dans un paquet IPv6 peut être difficile. Pire, certains équipements de sécurité et de transit sont connus pour s’attendre à trouver l’en-tête du protocole de couche supérieure juste après l’en-tête IPv6 obligatoire et échouent ainsi à le trouver ou à le reconnaître en présence d’en-têtes d’extension. Par exemple, de tels équipements échoueraient à reconnaître que le paquet ci-dessous est un segment TCP, simplement en raison de l’en-tête d’extension Destination Options.

 

Les équipements de sécurité implémentant cette logique erronée et qui ont en outre été configurés pour appliquer une politique du laisser-passer par défaut (à savoir : laisser passer tous les paquets ne validant aucune des règles spécifiées) pourront être victimes de techniques évasives. L’une d’entre elles consiste à définir des paquets contenant un nombre d’en-têtes d’extension supérieur à la limite d’inspection implémentée dans l’équipement de sécurité, ou bien des en-têtes d’extension d’une taille supérieure à la limite prévue par l’équipementier. L’ambiguïté dans la manière dont doivent être traités certains paquets dans des contextes de limites représente un autre vecteur d’évasion des contrôles de sécurité.

 

 

La fragmentation peut également être exploitée pour échapper à des contrôles de sécurité, en cachant soit le type du protocole de la couche supérieure, soit le flux de données applicatif. Au cours des récentes années, plusieurs implémentations se sont avérées vulnérables à plusieurs de ces techniques d’évasion. Par exemple, le RFC7113 décrit ce problème pour le cas de l’annonce de routeur (RA-Guard), mais les mêmes techniques peuvent être employées pour contourner certains pare-feux IPv6. En outre, des incohérences dans la manière dont certains paquets sont susceptibles d’être traités peuvent se traduire in fine par une évasion des contrôles de sécurité, comme l’ont montré Panos Kampanakis de Cisco et le chercheur Antonios Atlasis.

Les en-têtes d’extension d’IPv6 peuvent avoir un impact négatif sur les performances des équipements. Cela n’est pas vraiment un problème de sécurité, mais cela mérite que l’on s’y attarde. Par exemple, les implémentations de routeurs IPv6 traitent généralement les paquets contenant une en-tête d’extension Hop-by-Hop Options en logiciel plutôt qu’en matériel. D’autres implémentations sont connues pour traiter en logiciel les en-têtes d’extension IPv6 lorsqu’ils sont configurés pour faire respecter des listes de contrôle d’accès. Cela signifie que, à moins que les remèdes appropriés ne soient en place, des attaquants peuvent envoyer de vastes volumes de trafic IPv6 pour conduire des attaques en déni de service (DoS).

Bien que le protocole IPv6 – et de nombreuses implémentations – existe depuis plusieurs années, des bugs dans le traitement des en-têtes d’extension ont été récemment trouvés dans plusieurs implémentations. Il est probable que cela ne soit lié qu’à une chose : la plupart des en-têtes d’extension ne sont pas utilisés dans le trafic rencontré en ligne, et le code lié à leur traitement n’est que rarement mis à l’épreuve. Pour cette raison, il ne devrait pas être surprenant que des bugs, dans le traitement des en-têtes d’extension d’IPv6 continuent d’être découverts à l’avenir dans certaines implémentations.

Enfin, outre les implications de sécurité générale des en-têtes d’extension d’IPv6, chaque type d’en-tête d’extension tend à présenter ses propres implications. Par exemple, des chercheurs en sécurité ont montré, en 2007, comment utiliser le Routeur Header Type 0 (désormais désuet) pour lancer des attaques de type DoS. Le Fragment Header est également bien connu pour ses implications de sécurité.

Conclusion

La plupart – sinon toutes – les implications de sécurité liées aux en-têtes d’extension IPv6 tendent à être associées à la manière dont leur support a été implémenté : code buggé, ou équipements traitant les en-têtes d’extension en logiciel. Certaines implémentations peuvent offrir des techniques de remédiation, comme la possibilité de définir un débit limite de paquets IPv6 employant des en-têtes d’extension – pour abandonner le trafic conduisant à des conditions de DoS. Mais dans les autres cas, un administrateur peut n’avoir d’autre option que de filtrer le trafic correspondant. Clairement, cela représente un domaine de préoccupation que les responsables de la sécurité réseau doivent suivre étroitement alors que les déploiements d’IPv6 se poursuivent.

Adapté de l’anglais.

Pour approfondir sur Sécurité réseau (IDS, XDR, etc.)