Sårbarheter i Linux-kjernen, utnyttes eksternt via Bluetooth

En Linux-kjernen er det oppdaget en sårbarhet (CVE-2022-42896) som potensielt kan utnyttes for å utføre kode eksternt på kjernnivå ved å sende spesialtilpassede L2CAP-pakker via Bluetooth. I tillegg er det oppdaget et lignende problem (CVE-2022-42895) i L2CAP-behandleren, som kan føre til lekkasje av kjernens minne i pakker med konfigurasjonsinformasjon. Den første sårbarheten er aktiv siden august 2014 (kjerne 3.16), mens den andre har vært aktiv siden oktober 2011 (kjerne 3.0). Sårbarhetene er blitt utbedret i versjoner av Linux-kjernen 6.1.0, 6.0.8, 4.9.333, 4.14.299, 4.19.265, 5.4.224, 5.10.154 og 5.15.78. Du kan følge med på rettelsene i distribusjoner på følgende sider: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.

For å demonstrere muligheten for å utføre en ekstern angrep er det publisert prototyper av exploits som fungerer i Ubuntu 22.04. For å gjennomføre angrepet må angriperen være innen Bluetooth-rekkevidde — forhåndsparring er ikke nødvendig, men Bluetooth må være aktivert på datamaskinen. Det er tilstrekkelig å kjenne MAC-adressen til offeret, som kan fastsettes gjennom sniffing eller beregnes på noen enheter basert på MAC-adressen til Wi-Fi.

Den første sårbarheten (CVE-2022-42896) skyldes tilgang til allerede frigitt minneområde (use-after-free) i implementeringen av funksjonene l2cap_connect og l2cap_le_connect_req — etter opprettelsen av kanalen via callback-anropet new_connection ble det ikke satt en lås, men en timer (__set_chan_timer) ble konfigurert, som ved utløp av tidsbegrensningen kaller funksjonen l2cap_chan_timeout og frigjør kanalen uten å sjekke om arbeidet med kanalen var fullført i funksjonene l2cap_le_connect*.

Som standard er tidsbegrensningen 40 sekunder, og det ble antatt at en race condition ikke kunne oppstå med en slik forsinkelse. Det viste seg imidlertid at på grunn av en annen feil i SMP-behandleren kan timeren utløses umiddelbart, noe som fører til en race condition. Problemet i l2cap_le_connect_req kan føre til minnelekkasje i kjernen, mens l2cap_connect kan føre til overskriving av minneinnhold og utføring av egen kode. Den første angrepsmetoden kan utføres ved bruk av Bluetooth LE 4.0 (siden 2009), og den andre ved bruk av Bluetooth BR/EDR 5.2 (siden 2020).

Den andre sårbarheten (CVE-2022-42895) er forårsaket av lekkasje av resterende data fra minnet i funksjonen l2cap_parse_conf_req, noe som kan bli brukt til å hente informasjon om pekere til kjerneressurser eksternt ved å sende spesialtilpassede konfigurasjonsforespørsel. I funksjonen l2cap_parse_conf_req ble det brukt en struktur l2cap_conf_efs, hvor det ikke ble utført forhåndsinitialisering av tildelt minne, og gjennom manipulering med flagget FLAG_EFS_ENABLE kunne det bli oppnådd inbakt i pakken gamle data fra stakken. Problemet manifesterer seg bare i systemer der kjernen er kompilert med alternativet CONFIG_BT_HS (som standard deaktivert, men aktivert i noen distribusjoner, for eksempel Ubuntu). For et vellykket angrep kreves også at parameteren HCI_HS_ENABLED settes til true via kontrollgrensesnittet (som standard ikke i bruk).

Kilde: opennet.ru