Twee nuwe kwesbaarhede is geïdentifiseer in die eBPF-substelsel, wat jou toelaat om hanteerders binne die Linux-kern in 'n spesiale virtuele masjien met JIT te laat loop. Albei kwesbaarhede maak dit moontlik om jou kode met kernregte uit te voer, buite 'n geïsoleerde eBPF virtuele masjien. Inligting oor die probleme is gepubliseer deur die Zero Day Initiative-span, wat die Pwn2Own-kompetisie bestuur, waartydens vanjaar drie aanvalle op Ubuntu Linux gedemonstreer is wat voorheen onbekende kwesbaarhede gebruik het (of die kwesbaarhede in eBPF met hierdie aanvalle verband hou, word nie gerapporteer nie) .
- CVE-2021-3490 - Die kwesbaarheid word veroorsaak deur 'n gebrek aan 32-bis-buitegrens-kontrolering wanneer bitsgewys EN-, OF- en XOR-bewerkings in eBPF ALU32 uitgevoer word. 'n Aanvaller kan voordeel trek uit hierdie fout om data buite die grense van die toegewese buffer te lees en te skryf. Die probleem met XOR-bewerkings verskyn vanaf kernweergawe 5.7-rc1, en AND en OR - vanaf 5.10-rc1.
- CVE-2021-3489 - Die kwesbaarheid word veroorsaak deur 'n fout in die implementering van die ringbuffer en is te wyte aan die feit dat die bpf_ringbuf_reserve-funksie nie die moontlikheid nagegaan het dat die grootte van die toegewese geheuegebied minder as die werklike grootte kan wees nie van die ringbuf. Die probleem verskyn sedert vrystelling 5.8-rc1.
Die status van die herstel van kwesbaarhede in verspreidings kan op hierdie bladsye opgespoor word: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch). Regstellings is ook beskikbaar as pleisters (CVE-2021-3489, CVE-2021-3490). Of die probleem uitgebuit kan word, hang daarvan af of die eBPF-stelseloproep vir die gebruiker toeganklik is. Byvoorbeeld, in die verstekkonfigurasie in RHEL, vereis uitbuiting van die kwesbaarheid dat die gebruiker CAP_SYS_ADMIN-regte moet hê.
Afsonderlik kan ons op 'n ander kwesbaarheid in die Linux-kern let - CVE-2021-32606, wat 'n plaaslike gebruiker toelaat om hul voorregte tot die wortelvlak te verhoog. Die probleem is duidelik sedert Linux-kern 5.11 en word veroorsaak deur 'n rastoestand in die implementering van die CAN ISOTP-protokol, wat dit moontlik maak om die socket-binding parameters te verander as gevolg van die gebrek aan die opstel van die regte slotte in die isotp_setsockopt() funksie wanneer die CAN_ISOTP_SF_BROADCAST-vlag verwerk word.
Nadat die ISOTP-sok gesluit is, bly die binding aan die ontvanger-sok van krag, wat kan voortgaan om die strukture wat met die sok geassosieer word te gebruik nadat die geheue wat daarmee geassosieer word, vrygestel is (use-after-free as gevolg van die oproep na 'n isotp_sock-struktuur wat reeds vrygestel is wanneer isotp_rcv() geroep word). Deur data manipulasie kan jy die wyser na die sk_error_report() funksie ignoreer en jou kode op kernvlak uitvoer.
Bron: opennet.ru