Informasjon har blitt avslørt om en uopprettet (0-dagers) sårbarhet (CVE-2023-2156) i Linux-kjernen som gjør det mulig å stoppe systemet ved å sende spesiallagde IPv6-pakker (packet-of-death). Problemet vises bare når støtte for RPL-protokollen (Routing Protocol for Low-Power and Lossy Networks) er aktivert, som er deaktivert som standard i distribusjoner og brukes hovedsakelig på innebygde enheter som opererer i trådløse nettverk med høyt pakketap.
Sårbarheten er forårsaket av feil håndtering av eksterne data i RPL-protokollens parsing-kode, noe som fører til en assert-feil og at kjernen går i panikktilstand. Ved plassering av data oppnådd som et resultat av å analysere IPv6 RPL-pakkehodet i k_buff (Socket Buffer) strukturen, hvis CmprI-feltet er satt til 15, Segleft-feltet er satt til 1, og CmprE settes til 0, pakkes 48-byte vektoren med adresser ut til 528 byte når minnesituasjonen ikke er nok buffer for XNUMX byte. I dette tilfellet utløser skb_push-funksjonen som brukes til å skyve dataene inn i strukturen en sjekk for uforholdsmessig størrelse på dataene og bufferen, og genererer en panikktilstand for å forhindre overskriving av bufferen.
Utnyttelseseksempel: # Vi bruker Scapy til å lage pakken fra scapy.all import * import socket # Bruk IPv6 fra LAN-grensesnittet ditt DST_ADDR = sys.argv[1] SRC_ADDR = DST_ADDR # Vi bruker sockets for å sende pakken sockfd = socket.socket._Wsocket.socket._WSocket.Socket.Socket. .IPPROTO_RAW) # Lag pakken # Type = 6 gjør dette til en RPL-pakke # Adresser inneholder 3 adresser, men fordi CmprI er 3, # behandles hver oktett av de to første adressene som en komprimert adresse # Segleft = 15 for å utløse forsterkningen # lastentry = 1xrfI til 0mpSrc = 0xrf15 = 0xrf6 = 6xrf3 = 8xrf7 til 6 til 1 _ADDR, dst=DST_ADDR) / IPv0ExtHdrSegmentRouting( type=0, addresses=["a0::", "aXNUMX::", "aXNUMX::"], segleft=XNUMX, lastentry=XNUMXxfXNUMX) # Send denne onde pakken sockfd.sendto(bytes)_ADDR), (DST)
Det er bemerkelsesverdig at kjerneutviklerne ble varslet om sårbarheten tilbake i januar 2022 og i løpet av de siste 15 månedene prøvde de å fikse problemet tre ganger ved å gi ut patcher i september 2022, oktober 2022 og april 2023, men hver gang var ikke rettelsene nok og sårbarheten kunne reproduseres. Til syvende og sist bestemte ZDI-prosjektet, som koordinerte arbeidet med å eliminere sårbarheten, å avsløre detaljert informasjon om sårbarheten, uten å vente på at en fungerende patch skulle vises i kjernen.
Dermed er sårbarheten fortsatt uopprettet. Å inkludere oppdateringen som er inkludert i 6.4-rc2-kjernen er ikke effektiv. Brukere anbefales å bekrefte at RPL-protokollen ikke brukes på systemene deres, noe som kan gjøres ved å bruke sysctl -a | grep -i rpl_seg_enabled
Kilde: opennet.ru