I går informasjon ble gitt ut om et sikkerhetsproblem i Linux-kjernen og som allerede er katalogisert som CVE-2021-3609. Denne sårbarheten tillater en lokal bruker å heve sine privilegier på systemet på grunn av en løpstilstand i implementeringen av CAN BCM-protokollen og manifestert i versjoner 2.6.25 til 5.13-rc6 av Linux-kjernen.
Dommen utnytter fordi det CAN BCM-protokollen lar deg registrere din egen meldingsbehandling av kontrollerens nettverk (CAN) og koble den til en bestemt nettverkskontakt. Når en innkommende melding kommer, kalles funksjonen bcm_rx_handler () en angriper kan dra nytte av en løpetilstand og tvinge nettverkskontakten til å lukkes mens den kjøres bcm_rx_handler ().
Problemet kommer når stikkontakten er lukket og funksjonen kalles bcm_release (), hvor minne som er tildelt for strukturer frigjøres bcm_op og bcm_sock, som fortsatt brukes i handler bcm_rx_handler () som fremdeles er i gang, og dermed oppstår en situasjon som fører til tilgang til en allerede frigjort minneblokk (bruk etter-fri).
Dette er en kunngjøring av den nylig rapporterte feilen (CVE-2021-3609) i CAN BCM-nettverksprotokollen i Linux-kjernen fra versjon 2.6.25 til hovedlinje 5.13-rc6.
Sårbarheten er en løpsbetingelse i nett / can / bcm.c som gjør at eskalering av privilegier kan rotes. Problemet ble opprinnelig rapportert av syzbot og Norbert Slusarek viste seg å kunne utnyttes.
Angrepet går ut på å åpne to CAN BCM-stikkontakter og binde dem til vcan-grensesnittet. I den første kontakten ringer du sendmsg () med indikatoren RX_SETUP for å konfigurere kontrolleren for innkommende CAN-meldinger, og på den andre kontakten ringer du sendmsg () for å sende en melding til den første kontakten.
Etter at meldingen kommer, bcm_rx_handler () -anropet utløses og angriperen tar riktig øyeblikk og lukker den første kontakten, som fører til lanseringen av bcm_release () og lanseringen av strukturene bcm_op og bcm_sock, selv om arbeidet med bcm_rx_handler () ennå ikke fullført.
Ved å manipulere innholdet i bcm_sock, kan en angriper overstyre en peker til sk-> sk_data_ready (sk) -funksjonen, omdirigere utførelse, og ved å bruke retur-orientert programmering (ROP) teknikker, overstyre modprobe_path-parameteren og få koden til å kjøre som rot .
Når du bruker ROP-teknikken, prøver ikke angriperen å sette koden sin til minne om, men det fungerer bitene av maskininstruksjoner som allerede er tilgjengelige i lastede biblioteker, som ender med en uttalelse om kontrollretur (som regel er dette slutten på biblioteksfunksjonene).
Tillatelsene som kreves for å utføre et angrep kan anskaffes av en uprivilegert bruker i containere opprettet på systemer med brukernavnområder aktivert. For eksempel er brukernavnområder som standard inkludert i Ubuntu og Fedora, men ikke aktivert i Debian og RHEL.
Mitt utnyttelsesforsøk konsentrerer seg om kjerner med versjon> = 5.4-rc1 fra commit bf74aa86e111. Jeg undersøkte ikke utnyttelse av kjerner eldre enn 5.4-rc1 ved hjelp av oppgaver, men utnyttelse av eldre kjerner virker også mulig.
Det er nevnt at forskeren som identifiserte sårbarheten, var i stand til å forberede en utnyttelse for å få rotrettigheter på systemer med kjerner fra versjon 5.4 og senere, inkludert muligheten for et vellykket angrep på Ubuntu 20.04.02 LTS.
Arbeidet med utnyttelsen er redusert til å bygge en kjede av samtaler til lignende blokker ("gadgets") for å oppnå den nødvendige funksjonaliteten. Angrepet krever tilgang for å opprette CAN-stikkontakter og et konfigurert vcan-nettverksgrensesnitt.
Endelig det er nevnt at problemet fortsatt vedvarer på de fleste distribusjoner, men det er noen dager før de tilsvarende oppdateringene blir utgitt.
Hvis du er interessert i å vite mer om det, kan du konsultere følgende lenke.