harbingerse7en/cve-2024-20154Analisi tecnica di CVE-2024-20154, un buffer overflow basato su stack nel firmware del baseband NB-IoT MediaTek MT6769, che copre il reverse engineering e la catena di exploit.
Classificazione: CWE-121 — Stack-based Buffer Overflow
Gravità: Critica (bollettino MediaTek) · 8.8 Alta, Attack Vector: Adjacent (CISA-ADP)
Tipo: Remote Code Execution — nessuna interazione utente, nessuna associazione preventiva
Divulgazione: MediaTek Security Bulletin, 6 gennaio 2025 https://corp.mediatek.com/product-security-bulletin/January-2025
Target analizzato: Samsung Galaxy A14 SM-A145R — famiglia MT6769 (Helio G80), all'interno della lista di chipset interessati di MediaTek - Il firmware è stato emulato in condizioni sicure.
Stato: Corretto.
Questa è stata la mia prima ricerca pubblicata sul baseband. Provengo da un background molto distante dalle infrastrutture di telecomunicazione, dai livelli di mediazione per l'intercettazione legale, dall'analisi di stingray e IMSI-catcher, e dalla sicurezza dei dispositivi embedded — non avevo mai fatto in precedenza reverse engineering approfondito del firmware di un modem cellulare. Volevo dimostrare a me stesso che una metodologia analitica strutturata si adatta a target diversi, e che la familiarità con una piattaforma specifica può essere sostituita da un rigoroso chain-tracing. NB-IoT si è distinto perché si trova in un'intersezione genuinamente pericolosa: il protocollo è progettato per dispositivi IoT con risorse limitate, la superficie d'attacco è pre-associazione, e lo stack del modem lo elabora indipendentemente da ciò che l'utente del telefono sta facendo.
Quando il firmware corretto è stato analizzato e il pattern vulnerabile confermato assente, il sistema AI utilizzato per l'analisi di massa del firmware prima di prendere di mira funzioni specifiche
ha associato in modo indipendente la classe di bug ricostruita, le condizioni e la famiglia di firmware interessata alla descrizione di CVE-2024-20154.
Le conclusioni tecniche sono dell'analista.
Il telefono nella tua tasca contiene almeno due computer separati. Quello con cui interagisci esegue Android. L'altro — il baseband — funziona in modo completamente indipendente, gestisce tutte le comunicazioni radio, ed è quasi del tutto invisibile al sistema operativo sovrastante. Android può essere completamente aggiornato. Il browser può essere in sandbox. L'utente può non toccare mai un link malevolo. Niente di tutto ciò conta se il codice vulnerabile si trova nel firmware del modem che elabora i segnali radio prima che l'application processor sia coinvolto.
CVE-2024-20154 è esattamente questo tipo di vulnerabilità.
Una trasmissione di system-information NB-IoT malformata causa al firmware del modem MediaTek di accettare un conteggio di scheduling controllato dall'attaccante, di trasportare quel conteggio attraverso il percorso di configurazione RRC-to-L1 senza mai limitarlo, e infine di usarlo come limite di ciclo per un ciclo di scrittura sullo stack all'interno dell'handler del canale broadcast NB-IoT. Quando il conteggio supera la capacità degli array di destinazione, il ciclo scrive oltre essi, raggiunge i registri salvati sullo stack e sovrascrive l'indirizzo di ritorno salvato. La funzione quindi ripristina il valore corrotto nel registro dell'indirizzo di ritorno e salta ad esso.
Ciò che rende la gravità quella che è:
La vulnerabilità è stata pubblicata nel Security Bulletin di MediaTek del 6 gennaio 2025 con una valutazione di gravità Critica, che interessa tra gli altri la famiglia di modem LR12A. Samsung ha incorporato la correzione nella sua Security Maintenance Release di febbraio 2025.
Questo post non pubblica un exploit weaponizzato e non è riproducibile da ciò che è pubblicato qui. L'obiettivo è mostrare dove la catena si rompe, perché ogni livello ha fallito nel fermarla, e cosa serve per validare responsabilmente un bug del baseband quando non puoi collegare un debugger al modem live.
Target primario: Samsung Galaxy A14 (SM-A145R). Il sottosistema radio è pilotato da un processore baseband MediaTek della famiglia di chipset MT6769 (Helio G80). La famiglia MT6769 è esplicitamente elencata nella lista di chipset interessati di MediaTek per CVE-2024-20154.``` AP/CP firmware: A145RXXU1AWD1 Modem software: MOLY LR12A.R3.TC10.6M.A14.PR.SP.V1.P5 Build date: 2023-04-18
Il firmware del baseband non è codice Android. È un sistema embedded separato sul sottosistema radio del SoC con la propria CPU, il proprio RTOS e il proprio spazio di memoria, al di fuori del sandbox dei processi Android.
### 2.2 Architettura del modem
L'analisi del binario estratto mostra che il processore del modem esegue MIPS32 con istruzioni compresse MIPS16e2 in modalità little-endian. MIPS16e2 è un'estensione di codifica a 16 bit per la riduzione della dimensione del codice embedded — coerente con l'approccio di MediaTek per i baseband della generazione Helio, confermato da ricerche indipendenti pubblicate sui baseband di questa famiglia di SoC.
Il sistema operativo è Nucleus RTOS, che fornisce scheduling dei task, code di messaggi IPC e un allocatore di memoria basato su pool. Non esiste separazione dei privilegi kernel/user, né applicazione della memory protection unit tra i task, né meccanismo hardware di stack-guard.
Tutti gli indirizzi in questo post sono indirizzi virtuali, come caricati in Ghidra alla base `0x90000000`.
### 2.3 Mitigazioni (osservate nella build analizzata)
| Mitigazione | Stato | Effetto |
|---|---|---|
| ASLR | Assente | Gli indirizzi del firmware sono statici e prevedibili dall'immagine |
| Stack canary | Assente | `SAVE`/`RESTORE` salva i registri callee-saved senza valore di guardia |
| NX / W^X | Assente | La memoria dello stack è eseguibile |
| CFI | Assente | Gli indirizzi di ritorno non sono validati rispetto ad alcuna policy |
### 2.4 Approccio di analisi
Tre percorsi paralleli:
**Analisi statica.** Pacchetto firmware Samsung → estrazione partizione CP → `md1img.img` →
Ghidra (MIPS LE 32-bit, base `0x90000000`) con simboli di engineering MediaTek recuperati dalla
sezione di debug del firmware usando il toolset `mtk_bp` di NCC Group.
**Validazione dinamica.** Unicorn Engine (emulazione MIPS32) è stato usato per eseguire specifiche
routine del firmware in isolamento attraverso due fasi. La Fase 1 ha tentato di dimostrare la copia
non limitata di `si_count` nel contesto del canale attraverso la coppia di istruzioni native. La Fase 2 ha eseguito
il loop vulnerabile su byte reali del firmware e ha confermato che le istruzioni del firmware stesso
corrompono l'indirizzo di ritorno salvato. Dove la Fase 1 non ha potuto essere eseguita completamente in modo nativo — perché
l'ambiente degli oggetti di servizio RTOS richiesto dal percorso di dispatch CPHY non è stato ricostruito —
l'effetto collaterale è stato modellato direttamente ed etichettato come tale in tutto l'output.
**Validazione lato radio.** srsRAN 4G con un loopback ZMQ — solo software, nessuna emissione RF —
ha confermato che il payload di test sopravvive alla codifica PHY NB-IoT e alla consegna del transport block.
---
## 3. Superficie di attacco: NB-IoT e SIB1-NB
### 3.1 Superficie di attacco pre-associazione