CVE-2023-20768 sul Samsung Galaxy M32 — uno studio di raggiungibilità

Sommario. CVE-2023-20768 è una type confusion (CWE-843) nell'allocatore ION di MediaTek. Ho verificato se sia effettivamente sfruttabile su un Samsung SM-M325F (Galaxy M32, Helio G80) con il firmware di luglio 2022. Il codice vulnerabile è presente e ho dimostrato che viene eseguito su questo dispositivo quando viene attivato da un processo senza privilegi. Non sono riuscito a trasformarla in un exploit. Il percorso ioctl è limitato dalla validazione degli input, e il percorso che contiene la vera lettura fuori dai limiti elabora solo buffer ION autentici, perché un secondo controllo sul puntatore dma_buf_ops respinge qualunque cosa io possa falsificare. Questo writeup descrive come sono arrivato a questa conclusione, inclusa una conclusione intermedia che si è rivelata sbagliata.

La CVE è pubblica e corretta. Tutti i test sono stati eseguiti sul mio dispositivo personale, con root tramite Magisk.

Perché questo dispositivo

Il bug è nel codice ION di MediaTek, non nel Linux upstream né in qualcosa scritto da Samsung. MediaTek distribuisce un proprio fork dell'allocatore ION di Android nel BSP che viene fornito a ogni vendor che produce dispositivi con i suoi chip. La M32 usa un Helio G80, quindi riceve quel codice. Lo stesso telefono con un SoC Exynos non sarebbe affatto vulnerabile.

Causa principale

Ho estratto le immagini vmlinux del 2022 (vulnerabile) e del 2023 (corretta) e le ho confrontate in IDA. Due funzioni ION sono cambiate:

is_dma_buf_file non esiste nell'immagine del 2022. Appare in quella del 2023. Quindi entrambe le funzioni decidevano se un struct file fosse un dma_buf guardando un nome, e la correzione ha sostituito quel controllo con un vero type check. Confondere un oggetto qui significa che il kernel legge un non-dma_buf come se lo fosse.

Raggiungere il codice da userspace

Delle due, _ion_ioctl è quella che un processo senza privilegi può raggiungere:

open("/dev/ion")
  -> ion_ioctl                      (.unlocked_ioctl)
  -> ION_IOC_CUSTOM  (0xC0104906)
  -> ion_custom_ioctl
  -> _ion_ioctl
  -> case 0: ION_SYS_CACHE_SYNC
  -> find_vma(user_VA)              (call site at _ion_ioctl+0x9f0)
  -> strcmp(vma->vm_file...name, "ion")

La richiesta è un ion_custom_data { u32 cmd = 0; u64 arg; } che punta a un ion_sys_data di 120 byte:

spoof.c costruisce questa struttura.

Dimostrare che esegue il dispatch

Non potevo semplicemente tracciarlo. Il dispositivo blocca kprobe_events, set_ftrace_filter e function_graph tramite la policy SELinux e l'hardening del kernel di Samsung, e le printk di ION sono limitate al debug, quindi dmesg resta silenzioso.

Quindi ho usato i codici di ritorno come oracolo. Quattro richieste, e il pattern di ciò che viene restituito rivela dove è andata l'esecuzione:

Il successo di C significa che lo switch esegue davvero il dispatch su sys_cmd. La differenza tra A e B significa che la VA viene elaborata, il che porta l'esecuzione dentro find_vma. Questo è il percorso vulnerabile, raggiunto senza root.

Dove si è fermato

Raggiungere il controllo non equivale a superarlo. Ho testato cosa accetta realmente lo strcmp:

• Un vero buffer ION mappato tramite ION_IOC_SHARE e poi mmap passa, ritorna 0.
• Una memfd chiamata memfd:ion fallisce, -EFAULT.
• Un file normale chiamato letteralmente ion fallisce, -EFAULT.

Quindi il campo confrontato a vm_file+0x60 non è il nome del file. È interno a dma_buf, quasi certamente dma_buf->exp_name, che ION imposta su "ion". Il controllo è inaffidabile by design, ma nulla di ciò che posso creare da userspace può impostare quel campo.

Poi ho fatto fuzzing sul percorso: sync_type da 0 a 7, size {0, 1, 0x1000, 0x100000, 0xffffffff}, VA {vero buffer ion, memfd, 0}, 120 casi, più una sonda con handle liberato per una use-after-free. Nessun crash, il dispositivo è rimasto attivo. Le size eccessive escono prima di find_vma e ritornano 0. I sync type da 3 a 5 percorrono il percorso m4u e ritornano -EPERM. Qualunque valore sopra 5 ritorna -EINVAL. Un handle liberato ritorna -EINVAL, quindi ION lo valida e lì non c'è UAF.

L'altra funzione, e una svolta sbagliata

La vera lettura fuori dai limiti è in ion_drv_file_to_buffer. Esegue ldr [private_data+0x28], leggendo il private_data di un non-dma_buf come se fosse un dma_buf. C'è un confronto ops == &ion_dma_buf_ops (la tabella è a 0xFFFFFF800A097F18), ma avviene dopo quella lettura, quindi non la impedisce. A valle, __do_dump_share_fd legge i campi a +0x28, +0x48, +0x50, +0xb8, +0xe4 del buffer restituito e li stampa, e ldr x8, [buf+0x28]; ldr [x8+0x30] è una dereferenziazione di puntatore selvaggio per un oggetto confuso.

Il trigger è ion_dump_all_share_fds, che usa iterate_fd per scorrere i file descriptor di ogni processo client ION. La mia prima conclusione è stata che questo viene eseguito solo quando si legge un nodo debugfs di ION, e questo kernel ha CONFIG_DEBUG_FS non impostata. L'ho verificato in tre modi: /proc/config.gz, debugfs assente da /proc/filesystems, e mount -t debugfs che ritorna ENODEV. Ho archiviato il percorso come strutturalmente irraggiungibile.

Mi sbagliavo. dump_header, il memory dump dell'OOM killer, contiene un bl ion_mm_heap_memory_detail diretto a 0xffffff8008204b9c, e dump_header viene chiamata da out_of_memory e oom_kill_process. Nessun debugfs necessario.

memcg_oom.c lo conferma. Crea un cgroup sotto /dev/memcg, limita sia memory.limit_in_bytes che memory.memsw.limit_in_bytes a 8MB (limitare solo il primo consente al figlio di scappare nello swap zram), e fa il fork di un figlio che alloca finché non muore. dmesg quindi mostra:

dump_header <- oom_kill_process <- out_of_memory <- mem_cgroup_oom_synchronize

seguito dall'output completo di ion_mm_heap_memory_detail e __do_dump_share_fd che risolve i veri dma_buf di gralloc. Quindi la funzione vulnerabile viene eseguita, durante qualcosa che qualunque processo senza privilegi può causare. C'è anche un terzo trigger, ShowStatus da hang_detect_dump_thread nel watchdog di MediaTek.

Perché ancora non funziona

Ho tenuto aperte 32 memfd chiamate memfd:dmabuf e ho attivato lo stesso OOM memcg. Se una delle mie fosse stata passata a ion_drv_file_to_buffer, la strstr avrebbe avuto successo, private_data sarebbe stato NULL, e il kernel avrebbe stampato [ION]ion_drv_file_to_buffer warnning, dmabuf is NULL a KERN_ERR. Quella riga non è mai apparsa. Solo i client graphics e gralloc sono comparsi nel dump. O la tabella fd di un normale client /dev/ion non è ciò che iterate_fd scorre qui, oppure la memfd fallisce silenziosamente prima della stampa.

In ogni caso l'OOM dump gestisce solo i dma_buf legittimi del sistema, che passano senza problemi. memfd è anche l'unico tipo di fd il cui nome posso controllare abbastanza da contenere "dmabuf", e non può generare un fault.

Verdetto

La vulnerabilità è presente. Il codice vulnerabile è raggiungibile e viene effettivamente eseguito su questa build, attivabile senza root. Non è trasformabile in un exploit da userspace qui. Il percorso ioctl è limitato dalla validazione dell'handle, da un controllo della size e da access_ok. Il percorso di dump vede solo veri buffer ION, e la falsificazione è bloccata da ops == &ion_dma_buf_ops. Andare oltre richiederebbe un oggetto controllabile non ION il cui exp_name sia "ion", oppure una primitiva diversa come una UAF su un buffer ION, o una race TOCTOU.

File

• spoof.c — PoC dell'ioctl cache-sync e oracolo differenziale
• memcg_oom.c — trigger OOM memcg per il percorso di dump
• trigger.c, oom_trigger.c — tentativi di trigger precedenti
• boot_images/ — immagini del kernel estratte (2022 e 2023) e database IDA per la build del 2022