harbingerse7en/cve-2024-20154Technischer Bericht zur Analyse von CVE-2024-20154, einem stackbasierten Pufferüberlauf in der MediaTek MT6769 NB-IoT-Baseband-Firmware, einschließlich Reverse Engineering und Exploit-Kette.
Klassifizierung: CWE-121 — Stack-basierter Buffer Overflow
Schweregrad: Kritisch (MediaTek-Bulletin) · 8.8 Hoch, Angriffsvektor: Adjacent (CISA-ADP)
Typ: Remote Code Execution — keine Benutzerinteraktion, keine vorherige Assoziation
Offenlegung: MediaTek Security Bulletin, 6. Januar 2025 https://corp.mediatek.com/product-security-bulletin/January-2025
Analysiertes Ziel: Samsung Galaxy A14 SM-A145R — MT6769-Familie (Helio G80), innerhalb der von MediaTek aufgeführten betroffenen Chipsätze - Die Firmware wurde unter sicheren Bedingungen emuliert.
Status: Gepatcht.
Dies war meine erste veröffentlichte Baseband-Forschung. Ich komme aus einem Hintergrund, der weit entfernt ist von Telekommunikationsinfrastruktur, Mediationsschichten für rechtmäßige Überwachung, Stingray- und IMSI-Catcher-Analyse sowie Sicherheit eingebetteter Geräte — ich hatte zuvor kein tiefgehendes Firmware-Reverse-Engineering an einem zellularen Modem durchgeführt. Ich wollte mir selbst beweisen, dass eine strukturierte analytische Methodik sich über verschiedene Ziele hinweg anpassen lässt und dass Vertrautheit mit einer spezifischen Plattform durch rigoroses Chain-Tracing ersetzt werden kann. NB-IoT stach hervor, weil es an einer wirklich gefährlichen Schnittstelle liegt: Das Protokoll ist für ressourcenbeschränkte IoT-Geräte konzipiert, die Angriffsfläche besteht vor der Assoziation, und der Modem-Stack verarbeitet sie unabhängig davon, was der Handset-Nutzer gerade tut.
Als die gepatchte Firmware analysiert und das verwundbare Muster bestätigt als abwesend festgestellt wurde, ordnete das für die Massenanalyse der Firmware vor der gezielten Adressierung spezifischer Funktionen verwendete KI-System
unabhängig die rekonstruierte Fehlerklasse, die Bedingungen und die betroffene Firmware-Familie der Beschreibung von CVE-2024-20154 zu.
Die technischen Schlussfolgerungen sind die des Analysten selbst.
Das Telefon in Ihrer Tasche enthält mindestens zwei separate Computer. Derjenige, mit dem Sie interagieren, führt Android aus. Der andere — das Baseband — läuft völlig unabhängig, verarbeitet die gesamte Funkkommunikation und ist für das darüberliegende Betriebssystem nahezu unsichtbar. Android mag vollständig gepatcht sein. Der Browser mag sandboxed sein. Der Nutzer mag niemals auf einen bösartigen Link tippen. Nichts davon spielt eine Rolle, wenn der verwundbare Code in der Modem-Firmware liegt, die Funksignale verarbeitet, bevor der Anwendungsprozessor überhaupt beteiligt ist.
CVE-2024-20154 ist genau diese Art von Schwachstelle.
Eine fehlerhafte NB-IoT-Systeminformations-Rundsendung veranlasst die MediaTek-Modem-Firmware, eine angreiferkontrollierte Scheduling-Anzahl zu akzeptieren, diese Anzahl durch den RRC-zu-L1-Konfigurationspfad zu tragen, ohne sie jemals zu begrenzen, und sie schließlich als Schleifengrenze für eine stack-schreibende Schleife innerhalb des NB-IoT-Broadcast-Channel- Handlers zu verwenden. Wenn die Anzahl die Kapazität der Ziel-Arrays überschreitet, schreibt die Schleife über sie hinaus, erreicht gespeicherte Register auf dem Stack und überschreibt die gespeicherte Rücksprungadresse. Die Funktion stellt dann den korrumpierten Wert in das Rücksprungadressregister wieder her und springt dorthin.
Was die Schwere ausmacht:
Die Schwachstelle wurde in MediaTeks Security Bulletin vom 6. Januar 2025 mit einer Kritisch-Schweregradbewertung veröffentlicht und betrifft unter anderem die LR12A-Modem- Familie. Samsung integrierte den Fix in sein Security Maintenance Release vom Februar 2025.
Dieser Beitrag veröffentlicht keinen weaponisierten Exploit und ist anhand des hier Veröffentlichten nicht reproduzierbar. Das Ziel ist zu zeigen, wo die Kette bricht, warum jede Schicht versagt hat, sie aufzuhalten, und was nötig ist, um einen Baseband-Bug verantwortungsvoll zu validieren, wenn man keinen Debugger am Live-Modem anbringen kann.
Primäres Ziel: Samsung Galaxy A14 (SM-A145R). Das Funksubsystem wird von einem MediaTek- Baseband-Prozessor aus der MT6769-Chipsatzfamilie (Helio G80) angetrieben. Die MT6769-Familie ist ausdrücklich in MediaTeks Liste der betroffenen Chipsätze für CVE-2024-20154 aufgeführt.``` AP/CP firmware: A145RXXU1AWD1 Modem software: MOLY LR12A.R3.TC10.6M.A14.PR.SP.V1.P5 Build date: 2023-04-18
Die Baseband-Firmware ist kein Android-Code. Sie ist ein separates eingebettetes System
auf dem Funk-Subsystem des SoC mit eigener CPU, eigenem RTOS und eigenem Speicherbereich,
außerhalb der Android-Prozess-Sandbox.
### 2.2 Modem-Architektur
Die Analyse des extrahierten Binaries zeigt, dass der Modem-Prozessor MIPS32 mit MIPS16e2-
komprimierten Instruktionen im Little-Endian-Modus ausführt. MIPS16e2 ist eine 16-Bit-
Kodierungserweiterung zur Reduzierung der Codegröße in eingebetteten Systemen — konsistent
mit MediaTeks Ansatz für Basebands der Helio-Generation, bestätigt durch unabhängige
veröffentlichte Baseband-Forschung zu dieser SoC-Familie.
Das Betriebssystem ist Nucleus RTOS, das Task-Scheduling, IPC-Nachrichtenwarteschlangen und
einen pool-basierten Speicherallokator bereitstellt. Es gibt keine Kernel/User-
Privilegientrennung, keine Durchsetzung einer Speicherschutzeinheit zwischen Tasks und keinen
Hardware-Stack-Guard-Mechanismus.
Alle Adressen in diesem Beitrag sind virtuelle Adressen, wie sie in Ghidra mit Basis
`0x90000000` geladen werden.
### 2.3 Mitigationsmaßnahmen (beobachtet im analysierten Build)
| Mitigation | Status | Wirkung |
|---|---|---|
| ASLR | Fehlt | Firmware-Adressen sind statisch und aus dem Image vorhersagbar |
| Stack Canary | Fehlt | `SAVE`/`RESTORE` speichert callee-saved Register ohne Guard-Wert |
| NX / W^X | Fehlt | Stack-Speicher ist ausführbar |
| CFI | Fehlt | Rücksprungadressen werden gegen keine Policy validiert |
### 2.4 Analyseansatz
Drei parallele Spuren:
**Statische Analyse.** Samsung-Firmware-Paket → CP-Partition-Extraktion → `md1img.img` →
Ghidra (MIPS LE 32-Bit, Basis `0x90000000`) mit MediaTek-Engineering-Symbolen, die aus dem
Firmware-Debug-Bereich mit dem NCC Group `mtk_bp`-Toolset wiederhergestellt wurden.
**Dynamische Validierung.** Unicorn Engine (MIPS32-Emulation) wurde verwendet, um bestimmte
Firmware-Routinen isoliert über zwei Phasen auszuführen. Phase 1 versuchte, die ungeklemmte
Kopie von `si_count` in den Kanal-Kontext durch das native Instruktionspaar zu beweisen.
Phase 2 führte die verwundbare Schleife auf echten Firmware-Bytes aus und bestätigte, dass
die Firmware-eigenen Instruktionen die gespeicherte Rücksprungadresse korrumpieren. Wo Phase 1
nicht vollständig nativ ausgeführt werden konnte — weil die vom CPHY-Dispatch-Pfad benötigte
RTOS-Service-Object-Umgebung nicht rekonstruiert wurde — wurde der Seiteneffekt direkt
modelliert und als solcher in allen Ausgaben gekennzeichnet.
**Funkseitige Validierung.** srsRAN 4G mit einem ZMQ-Loopback — rein softwarebasiert, keine
RF-Emission — bestätigte, dass die Test-Payload die NB-IoT-PHY-Kodierung und Transportblock-
Zustellung übersteht.
---
## 3. Angriffsfläche: NB-IoT und SIB1-NB
### 3.1 Angriffsfläche vor der Assoziierung