Kritischer Exploit in MediaTek-Wi‑Fi-Chipsätzen: Zero-Click-Schwachstelle

 (blog.sonicwall.com)
1 Punkte von GN⁺ 2024-09-22 | 1 Kommentare | Auf WhatsApp teilen

Schwere Schwachstelle in MediaTek-Wi‑Fi-Chipsätzen: Zero-Click-Schwachstelle (CVE-2024-20017) bedroht Router und Smartphones

Überblick
  • Das Threat-Research-Team von SonicWall Capture Labs hat die Schwachstelle CVE-2024-20017 erkannt, ihre Auswirkungen bewertet und Maßnahmen zur Eindämmung entwickelt
  • CVE-2024-20017 ist eine kritische Zero-Click-Schwachstelle mit einem CVSS-3.0-Score von 9.8 und betrifft die MediaTek-Wi‑Fi-Chipsätze MT7622/MT7915 sowie RTxxxx-SoftAP-Treiber-Bundles
  • Betroffen sind MediaTek SDK Version 7.4.0.1 und frühere Versionen sowie OpenWrt 19.07 und 21.02, die in Produkten verschiedener Hersteller wie Ubiquiti, Xiaomi und Netgear verwendet werden
  • Die Schwachstelle ermöglicht Remote Code Execution ohne Benutzerinteraktion, und MediaTek hat Patches zur Eindämmung bereitgestellt
  • Die Schwachstelle wurde im März offengelegt und gepatcht, doch durch ein kürzlich veröffentlichtes PoC ist die Wahrscheinlichkeit einer Ausnutzung gestiegen
Technischer Überblick
  • Die Schwachstelle befindet sich in wappd, einem Netzwerk-Daemon im MediaTek-MT7622/MT7915-SDK und in RTxxxx-SoftAP-Treiber-Bundles
  • wappd ist für die Konfiguration und Verwaltung von Wireless-Interfaces und Access Points zuständig und steht insbesondere mit der Hotspot-2.0-Technologie in Zusammenhang
  • Die Architektur von wappd besteht aus dem Netzwerkdienst selbst, einem Satz lokaler Dienste, die mit den Wireless-Interfaces des Geräts interagieren, sowie einem Kommunikationskanal zwischen den Komponenten über Unix-Domain-Sockets
  • Die Schwachstelle entsteht durch einen Buffer Overflow, weil ein direkt aus paketgesteuerten Daten übernommener Längenwert für eine Speicherkopie verwendet wird
Auslösen der Schwachstelle
  • Die Schwachstelle tritt in der Funktion IAPP_RcvHandlerSSB auf, wobei ein vom Angreifer kontrollierter Längenwert an das Makro IAPP_MEM_MOVE übergeben wird
  • Abgesehen von der Prüfung, dass die maximale Paketlänge 1600 Byte nicht überschreitet, gibt es keine Boundary Checks
  • Der Angreifer muss ein Paket senden, bei dem die erwartete Struktur dem Angriffs-Payload vorangestellt ist
  • Die Länge der Struktur RT_IAPP_HEADER muss klein sein, und das Feld RT_IAPP_HEADER.Command muss 50 sein
Ausnutzung
  • Öffentlich verfügbarer Exploit-Code erreicht Remote Code Execution mithilfe einer ROP-Chain und einer Technik zum Überschreiben der Global Offset Table
  • Dabei wird ein Aufruf von system() genutzt, um einen Befehl auszuführen, der eine Reverse Shell an den Angreifer sendet
  • Die Reverse Shell wird mit Bash- und Netcat-Tools eingerichtet
SonicWall-Schutz
  • Damit SonicWall-Kunden sich vor einer Ausnutzung dieser Schwachstelle schützen können, wurden die folgenden Signaturen bereitgestellt
    • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
    • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2
Empfehlungen zur Eindämmung
  • Da Exploit-Code veröffentlicht wurde, wird Nutzern dringend empfohlen, auf die neueste Firmware-Version für die betroffenen Chipsätze zu aktualisieren
Relevante Links

Zusammenfassung von GN⁺

  • Dieser Artikel behandelt eine kritische Zero-Click-Schwachstelle in MediaTek-Wi‑Fi-Chipsätzen, die Remote Code Execution ohne Benutzerinteraktion ermöglicht
  • Das Forschungsteam von SonicWall hat die Schwachstelle erkannt und Gegenmaßnahmen entwickelt und empfiehlt Nutzern ein Upgrade auf die neueste Firmware
  • Die Schwachstelle betrifft Router und Smartphones verschiedener Hersteller, und durch ein kürzlich veröffentlichtes PoC ist die Wahrscheinlichkeit einer Ausnutzung gestiegen
  • Ein Produkt mit ähnlichen Funktionen sind die Wi‑Fi-Chipsätze von Qualcomm; wichtig ist, regelmäßig nach Sicherheitsupdates zu suchen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-22
Meinungen auf Hacker News

  • Aus der Perspektive von jemandem, der den Quellcode der Treiber aus MediaTeks Vendor-SDK mit mt76 verglichen hat, ist das nicht besonders überraschend. Wohlwollend gesagt ist er ziemlich chaotisch.
    Leider gibt es auch einige Third-Party-Firmware-Builds mit Vendor-Treibern, weil sie etwas mehr Durchsatz liefern als mt76.
    Zum Glück gibt es bei MediaTek und in der WiSoC-Abteilung einige Engineers, die aktiv mit der Free- und Open-Source-Software-Community kommunizieren, und sie pflegen auch selbst einen kleinen OpenWrt-Fork auf mt76-Basis: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...

    • Ich weiß nicht, warum sich solche Hardware/Firmware immer so anfühlt, als würde Proof-of-Concept-Code in die Produktion ausgerollt. Können die nicht Leute einstellen, die wissen, was sie tun?
    • Ich frage mich, ob es eine Pressemitteilung oder Informationen dazu gibt, was das Ziel dieses Programms ist oder wie viel von diesem Feed upstream gemergt wurde.

  • Die Formulierung des Titels ist etwas irreführend. Ich habe zu Hause ein paar Router mit mt76-Wi-Fi und habe auf den Link geklickt, weil ich dachte, es gehe um einen Firmware- oder Silizium-Bug; dann war ich erleichtert, als sich herausstellte, dass es ein Bug im SDK-Gerümpelcode des Vendors ist.
    Ich verstehe nicht, warum jemand diesen verwenden wollte, obwohl die mt76-Unterstützung im Mainline-Kernel und in hostapd ziemlich gut ist.

    • Für „ich war erleichtert, dass es ein Bug im SDK-Gerümpelcode des Vendors ist“ gibt es gleich mehrere Vendoren, um die man sich Sorgen machen muss.
      Dort steht: „ein Treiber-Bundle, das in Produkten mehrerer Hersteller verwendet wurde, darunter Ubiquiti, Xiaomi, Netgear und andere“.
      Allerdings gibt es auch Vendoren wie Ubiquiti, die erklärt haben, dass sie es in ihren tatsächlichen Produkten nicht verwenden: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
    • Die OpenWRT-21.02.x-Reihe soll betroffen sein, obwohl sie auf Mainline-Kernel 5.4 basiert. Diese Leute kennen sich mit Linux-Wireless-Networking ziemlich gut aus, und meines Wissens wird der mt76-Treiber im Mainline-Kernel tatsächlich von einem OpenWRT-Entwickler gepflegt.

  • Ursprünglicher Blogpost: https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...

    • Der wappd-Dienst wird hauptsächlich genutzt, um den Betrieb von Wireless-Interfaces und Access Points mithilfe von Hotspot 2.0 und verwandten Technologien zu konfigurieren und zu koordinieren.
      Die Anwendungsarchitektur ist etwas komplex, besteht im Kern aber aus einem Netzwerkdienst, lokalen Diensten, die mit den Wireless-Interfaces des Geräts interagieren, sowie Kommunikationskanälen zwischen Komponenten über Unix-Domain-Sockets.
      Ein kleiner Trost ist, dass das eher nach einem Problem in einem „Value-add“-Dienst klingt, der für den eigentlichen Betrieb der WLAN-Karte nicht zwingend nötig ist, und nicht nach einem Bug in der Baseband-Firmware.
      Das erinnert an Treiberpakete mancher Geräte, bei denen der eigentliche Treiber klein und unauffällig ist, aber zusammen mit Bloatware, die um mehrere Größenordnungen größer ist, für Funktionen installiert wird, die 99 % der Nutzer weder brauchen noch wollen. Drucker und GPUs sind dabei besonders schlimm.

  • Ich frage mich, ob es irgendeine Logik hinter MediaTeks Namensschema gibt, oder ob jedes Gerät einfach MTxxxx heißt und x ein hochgezählter Wert oder eine Zufallszahl ist.
    Ich habe ein Gerät mit einem mt6631-Wi-Fi-Chip; da er nicht auf der Betroffenenliste steht, kann ich zwar annehmen, dass ich in Ordnung bin, aber es ist schwer zu erkennen, wo er in der Produktfamilie einzuordnen ist.

  • OpenWrt 19.07 und 21.02 sollen betroffen sein, aber soweit ich sehe, verwenden die offiziellen OpenWrt-Builds nur den mt76-Treiber und nicht das Mediatek-SDK.

  • Ich weiß nicht, warum beim Kauf eines Laptops mit AMD-CPU immer eine MediaTek-RZ616-Wi-Fi-Karte dabei ist.
    Ich habe sie alle durch Intel-Wi-Fi-Karten ersetzt, und jetzt habe ich einen Stapel RZ616-Karten, der zu zukünftigem Mikroplastik werden wird.

    • Intel verkauft Wi-Fi-Karten in zwei Varianten. Modelle mit einer 1 am Ende verwenden das CNVI-Protokoll, funktionieren nur mit Intel-Chips und werden sehr günstig an OEMs verkauft.
      Modelle mit einer 0 am Ende verwenden Standard-PCIe und kosten OEMs ungefähr 10 Dollar mehr.
      AMD hat MediaTek MT7921 und MT7922 in RZ608 bzw. RZ616 umbenannt, um OEMs etwas anbieten zu können, das preislich mit Intels xx1-Chips mithalten kann.
    • Auch Lenovo wurde mit MediaTek unzufrieden und begann, auf AMD-Plattformen Qualcomm-Chips für WLAN zu verlöten, wurde dann aber unter Linux erneut von einem Bug in der Interaktion zwischen Firmware und Treiber getroffen. Und das, obwohl Lenovo Linux offiziell verkauft und unterstützt.
      Sobald eine Chipsatzgeneration nicht mehr ganz aktuell ist, wird Qualcomms Support für den Mainline-Kernel ziemlich dünn. Heutzutage braucht es enormen Druck von Vendoren, um Qualcomm in Bewegung zu bringen.
    • iwlwifi hat ebenfalls eigene Probleme; das größte ist, dass es keinen 5-GHz-AP-Modus gibt. Auch die Intel-Firmware-Lizenz ist restriktiver als die von MediaTek, und da es fullmac ist, übernimmt die Firmware viel mehr Arbeit.
      Persönlich bevorzuge ich softmac. Heutzutage gibt es kaum noch gute Optionen, und die goldene Ära von ath9k ist vorbei.
    • Ich frage mich, ob du sie tatsächlich benutzt hast, abgesehen von einem bloßen „MediaTek vertraue ich nicht“.
      Ich hatte nacheinander ein Intel-ThinkPad und ein AMD-ThinkPad für die Arbeit, und das Wi-Fi mit MediaTek-Chipsatz im AMD-Gerät war deutlich besser als der Intel-Chipsatz im Intel-Gerät.
      Beim Intel-Gerät brach die Netzwerkverbindung mehrmals pro Stunde ab, und selbst auf 5 GHz war die Latenz beim Verwenden von ssh sofort spürbar schrecklich. Mein aktuelles Gerät mit MT7921 war unter Linux in den letzten zwei bis drei Jahren sehr stabil.
      Am Ende scheint es ziemlich stark von der Kombination aus Chipsatz und Laptop abzuhängen.

  • Soweit ich mich erinnere, verwendet auch mein Telefon einen MediaTek-Chipsatz. Und ich erinnere mich vage, dass der Grund, warum der Hersteller später von MediaTek weggegangen ist, die, nun ja, Qualität dieser Produkte war.
    Ich weiß nicht, wie Wi-Fi auf Telefonen aufgebaut ist. Gibt es eine Möglichkeit zu prüfen, ob dieses Telefon betroffen ist? Ich nutze Wi-Fi kaum, weil ich unbegrenzte mobile Daten und gute Abdeckung habe, aber es wäre trotzdem gut zu wissen.

    • In termux "sudo su" ausführen und dann ls /sys/module ansehen.
      Die Ausgabe sieht ähnlich aus wie lsmod.

  • Selbst in einer Zeit wie heute, in der Leute praktisch jedes verfügbare Silizium kaufen, verstehe ich immer noch nicht, warum solche C-Klasse-Vendoren nicht der PC-Strategie folgen und die Firmware komplett öffnen, um sie der Open-Source-Community zu überlassen.

    • Meist führen FCC-Vorschriften, die das Senden außerhalb zugelassener Frequenzbänder erschweren sollen, zu solchen Situationen.

  • Dort heißt es: „Zu den betroffenen Versionen gehören MediaTek SDK 7.4.0.1 und älter sowie OpenWrt 19.07, 21.02“, und „die Schwachstelle befindet sich im Netzwerk-Daemon wappd, der im MediaTek MT7622/MT7915 SDK sowie im RTxxxx-SoftAP-Treiber-Bundle enthalten ist“; tatsächlich scheint OpenWRT wappd aber gar nicht zu verwenden.

    • Als OpenWrt-Contributor frage ich mich, warum Leute OpenWrt und proprietäre Vendor-SDKs nicht auseinanderhalten. Wenn Nobara einen Bug hätte, würde man schließlich auch nicht Fedora erwähnen.
    • Ich habe mich dasselbe gefragt, weil ich in meinem Heimnetz mehrere Netgear-APs mit OpenWRT betreibe. Wenn diese Erklärung stimmt, bin ich dann in Ordnung?

  • Deshalb brauchen wir freie Firmware. Broadcom und Ralink habe ich inzwischen satt.