ieri au fost publicate informații despre o vulnerabilitate în nucleul Linux și care este deja catalogat ca CVE-2021-3609. Această vulnerabilitate permite unui utilizator local să își ridice privilegiile asupra sistemului datorită unei condiții de cursă în implementarea protocolului CAN BCM și manifestată în versiunile 2.6.25 până la 5.13-rc6 ale kernel-ului Linux.
Hotărârea profită deoarece Protocolul CAN BCM vă permite să vă înregistrați propriul manager de mesaje a rețelei de suprafață a controlorului (CAN) și conectați-l la o priză de rețea specifică. Când sosește un mesaj primit, funcția este apelată bcm_rx_handler () un atacator poate profita de o condiție de cursă și forța socket-ul de rețea să se închidă în timpul executării bcm_rx_handler ().
Problema apare atunci când soclul este închis iar funcția se numește bcm_release (), în care memoria alocată pentru structuri este eliberată bcm_op și bcm_sock, care continuă să fie utilizate în handler bcm_rx_handler () care încă funcționează, astfel apare o situație care duce la accesul la un bloc de memorie deja eliberat (utilizare-după-liber).
Acesta este un anunț al erorii raportate recent (CVE-2021-3609) în protocolul de rețea CAN BCM din nucleul Linux, variind de la versiunea 2.6.25 până la linia principală 5.13-rc6.
Vulnerabilitatea este o condiție de cursă în net / can / bcm.c care permite rootarea escaladării de privilegii. Problema a fost raportată inițial de syzbot și Norbert Slusarek s-a dovedit a fi exploatabil.
Atacul se reduce la deschiderea a două socluri CAN BCM și la legarea lor la interfața vcan. În primul conector, sunați sendmsg () cu indicatorul RX_SETUP pentru a configura controlerul pentru mesajele CAN primite și pe al doilea conector, sunați sendmsg () pentru a trimite un mesaj primului conector.
După sosirea mesajului, apelul bcm_rx_handler () este declanșat și atacatorul ia momentul potrivit și închide primul socket, ceea ce duce la lansarea bcm_release () și lansarea structurilor bcm_op și bcm_sock, deși opera lui bcm_rx_handler () nu a fost încă finalizat.
Prin manipularea conținutului bcm_sock, un atacator poate suprascrie un pointer la funcția sk-> sk_data_ready (sk), redirecționa execuția și, folosind tehnici de programare orientată pe returnare (ROP), poate suprascrie parametrul modprobe_path și face codul să ruleze ca root .
Când folosește tehnica ROP, atacatorul nu încearcă să-și pună codul in memoria, dar operează piese de instrucțiunile mașinii sunt deja disponibile în bibliotecile încărcate, care se termină cu o instrucțiune return return (de regulă, acestea sunt sfârșitul funcțiilor bibliotecii).
Permisiunile necesare pentru a efectua un atac pot fi dobândite de un utilizator neprivilegiat în containere create pe sisteme cu spații de nume de utilizator activate. De exemplu, spațiile de nume ale utilizatorilor sunt incluse în mod implicit în Ubuntu și Fedora, dar nu sunt activate în Debian și RHEL.
Încercarea mea de exploatare se concentrează pe nucleele cu versiunea> = 5.4-rc1 din commit bf74aa86e111. Nu am investigat exploatarea nucleelor mai vechi de 5.4-rc1 folosind tasklets, totuși exploatarea nucleelor mai vechi pare fezabilă și.
Se menționează că cercetătorul care a identificat vulnerabilitatea a reușit să pregătească un exploit pentru a obține drepturi de rădăcină pe sistemele cu nuclee de la versiunea 5.4 și ulterioară, inclusiv posibilitatea unui atac reușit pe Ubuntu 20.04.02 LTS.
Activitatea exploitului se reduce la construirea unui lanț de apeluri către blocuri similare („gadget-uri”) pentru a obține funcționalitatea necesară. Atacul necesită acces pentru a crea socluri CAN și o interfață de rețea vcan configurată.
În cele din urmă se menționează că problema persistă pe majoritatea distribuțiilor, dar este o chestiune de zile înainte ca patch-urile corespunzătoare să fie lansate.
Dacă sunteți interesat să aflați mai multe despre asta, puteți consulta următorul link.