Exploit critique dans les chipsets Wi‑Fi de MediaTek : une vulnérabilité zero-click

 (blog.sonicwall.com)
1 points par GN⁺ 2024-09-22 | 1 commentaires | Partager sur WhatsApp

Vulnérabilité grave dans les chipsets Wi‑Fi de MediaTek : la faille zero-click (CVE-2024-20017) menace les routeurs et les smartphones

Aperçu
  • L’équipe de recherche sur les menaces de SonicWall Capture Labs a identifié la vulnérabilité CVE-2024-20017, évalué son impact et développé des mesures d’atténuation
  • CVE-2024-20017 est une vulnérabilité zero-click critique avec un score CVSS 3.0 de 9,8, qui affecte les chipsets Wi‑Fi MediaTek MT7622/MT7915 ainsi que les bundles de pilotes RTxxxx SoftAP
  • Les versions 7.4.0.1 et antérieures du SDK MediaTek, utilisées dans des produits de divers fabricants comme Ubiquiti, Xiaomi et Netgear, ainsi que OpenWrt 19.07 et 21.02, sont affectées
  • Cette vulnérabilité permet une exécution de code à distance sans interaction de l’utilisateur, et MediaTek a diffusé un correctif pour en limiter l’impact
  • La vulnérabilité a été divulguée et corrigée en mars, mais un PoC rendu public récemment augmente le risque d’exploitation
Aperçu technique
  • La vulnérabilité se trouve dans wappd, un démon réseau inclus dans le SDK MediaTek MT7622/MT7915 et les bundles de pilotes RTxxxx SoftAP
  • wappd sert à configurer et gérer les interfaces sans fil et les points d’accès, en particulier dans le cadre de la technologie Hotspot 2.0
  • L’architecture de wappd se compose du service réseau lui-même, d’un ensemble de services locaux interagissant avec les interfaces sans fil de l’appareil, et d’un canal de communication entre composants via des sockets de domaine Unix
  • La vulnérabilité est causée par un buffer overflow, lorsqu’une valeur de longueur directement extraite de données de paquet contrôlées par l’attaquant est utilisée pour une copie mémoire
Déclenchement de la vulnérabilité
  • La vulnérabilité se produit dans la fonction IAPP_RcvHandlerSSB, où une valeur de longueur contrôlée par l’attaquant est transmise à la macro IAPP_MEM_MOVE
  • Aucune vérification de limites n’est effectuée, hormis le contrôle que la longueur maximale du paquet ne dépasse pas 1 600 octets
  • L’attaquant doit envoyer un paquet en préfixant sa charge utile avec la structure attendue
  • La longueur de la structure RT_IAPP_HEADER doit être faible, et le champ RT_IAPP_HEADER.Command doit valoir 50
Exploitation
  • Le code d’exploit publié utilise une chaîne ROP pour obtenir une exécution de code à distance via une technique d’écrasement de la table globale des adresses
  • Il exploite un appel à system() pour exécuter une commande envoyant un reverse shell à l’attaquant
  • Le reverse shell est mis en place avec les outils Bash et Netcat
Protection SonicWall
  • Les signatures suivantes ont été déployées pour permettre aux clients SonicWall de se protéger contre l’exploitation de cette vulnérabilité
    • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
    • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2
Recommandations d’atténuation
  • Comme le code d’exploit a été rendu public, il est fortement recommandé aux utilisateurs de mettre à niveau le firmware vers la dernière version disponible pour les chipsets concernés
Liens associés

Le récapitulatif de GN⁺

  • Cet article traite d’une vulnérabilité zero-click critique dans les chipsets Wi‑Fi de MediaTek, qui permet une exécution de code à distance sans interaction de l’utilisateur
  • L’équipe de recherche de SonicWall a identifié cette vulnérabilité et développé des mesures d’atténuation, tout en recommandant aux utilisateurs de passer au dernier firmware
  • La vulnérabilité affecte les routeurs et smartphones de divers fabricants, et le PoC récemment publié accroît le risque d’exploitation
  • Parmi les produits dotés de fonctionnalités similaires figurent les chipsets Wi‑Fi de Qualcomm, et il est important de vérifier régulièrement la disponibilité des mises à jour de sécurité

À lire aussi

1 commentaires

 
GN⁺ 2024-09-22
Avis sur Hacker News

  • Pour avoir comparé le code source des pilotes du SDK fournisseur de MediaTek avec mt76, ce n’est pas vraiment surprenant. Pour le dire gentiment, c’est assez brouillon.
    Malheureusement, comme le débit est un peu meilleur qu’avec mt76, il existe aussi quelques builds de firmwares tiers qui embarquent les pilotes du fournisseur.
    Heureusement, chez MediaTek et dans la division WiSoC, il y a quelques ingénieurs qui échangent activement avec la communauté du logiciel libre et open source, et ils maintiennent eux-mêmes un petit fork d’OpenWrt basé sur mt76 : https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...

    • Je ne comprends pas pourquoi ce genre de matériel/firmware donne autant l’impression qu’on a déployé du code de preuve de concept en production. Ils ne peuvent pas embaucher des gens qui savent vraiment ce qu’ils font ?
    • Je me demande s’il existe un communiqué de presse ou des informations sur l’objectif de ce programme, ou sur la part de ce feed qui a été fusionnée dans les projets amont.

  • Le titre est un peu trompeur. J’ai quelques routeurs à la maison avec du Wi-Fi mt76, donc j’ai cliqué en pensant qu’il s’agissait d’un bug de firmware ou de silicium, mais j’ai été rassuré de voir qu’il s’agissait en fait d’un bug dans le fourre-tout du SDK fournisseur.
    Alors que la prise en charge de mt76 dans le noyau mainline et hostapd est plutôt bonne, je ne comprends pas que quelqu’un ait voulu utiliser ça.

    • Dire « j’ai été rassuré de voir que c’était un bug dans le fourre-tout du SDK fournisseur » est un peu léger : il y a plusieurs fournisseurs dont il faut se préoccuper.
      Il est écrit qu’il s’agit d’un « bundle de pilotes utilisé dans des produits de plusieurs fabricants, dont Ubiquiti, Xiaomi, Netgear, etc. ».
      Cela dit, certains fournisseurs, comme Ubiquiti, ont indiqué ne pas l’utiliser dans leurs produits réels : https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
    • Il est indiqué que la branche OpenWRT 21.02.x est touchée, même si elle est basée sur le noyau mainline 5.4. Les gens de ce côté-là connaissent plutôt bien le réseau sans fil sous Linux et, si je ne me trompe pas, le pilote mt76 du noyau mainline est justement maintenu par un développeur OpenWRT.

  • Blog d’origine : https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...

    • Le service wappd sert surtout à configurer et coordonner les interfaces sans fil et le fonctionnement des points d’accès via Hotspot 2.0 et des technologies associées.
      La structure de l’application est assez complexe, mais elle se compose essentiellement d’un service réseau, de services locaux qui interagissent avec les interfaces sans fil de l’appareil, et d’un canal de communication entre composants utilisant des sockets de domaine Unix.
      Le point un peu rassurant, c’est que cela ressemble davantage à un problème dans un service « à valeur ajoutée » qui n’est pas strictement nécessaire au fonctionnement de la carte réseau sans fil elle-même, plutôt qu’à un bug dans le firmware de bande de base.
      Cela rappelle la façon dont certains packages de pilotes installent un vrai pilote petit et discret, mais l’accompagnent d’un bundleware plusieurs ordres de grandeur plus volumineux pour des fonctions dont 99 % des utilisateurs n’ont pas besoin et ne veulent pas. Les imprimantes et les GPU sont particulièrement mauvais là-dessus.

  • Je me demande s’il y a une logique dans la convention de nommage de MediaTek, ou si tous les appareils sont simplement des MTxxxx avec des x qui sont des valeurs incrémentales ou aléatoires.
    J’ai un appareil avec une puce Wi-Fi mt6631 ; comme elle n’est pas dans la liste des produits touchés, je peux supposer que ça va, mais il est difficile de savoir où elle se situe dans la gamme.

  • Il est dit qu’OpenWrt 19.07 et 21.02 sont touchés, mais à première vue les builds OpenWrt officiels semblent n’utiliser que le pilote mt76, pas le SDK Mediatek.

  • Je ne comprends pas pourquoi les PC portables avec CPU AMD sont toujours livrés avec une carte Wi-Fi MediaTek RZ616.
    Je les ai toutes remplacées par des cartes Wi-Fi Intel, et j’ai maintenant une pile de cartes RZ616 destinées à devenir les microplastiques de demain.

    • Intel vend deux types de cartes Wi-Fi. Les modèles dont le numéro se termine par 1 utilisent le protocole CNVI et ne fonctionnent qu’avec des puces Intel ; ils sont vendus très bon marché aux OEM.
      Les modèles dont le numéro se termine par 0 utilisent du PCIe standard et sont vendus aux OEM environ 10 dollars de plus.
      AMD a simplement rebadgé les MediaTek MT7921 et MT7922 en RZ608 et RZ616 afin d’avoir quelque chose à vendre aux OEM au même niveau de prix que les puces Intel xx1.
    • Lenovo aussi en a eu assez de MediaTek et a commencé à souder des puces Qualcomm pour le WLAN sur les plateformes AMD, mais s’est de nouveau fait avoir sous Linux à cause de bugs d’interaction entre firmware et pilote. Et pourtant Lenovo vend et prend officiellement en charge Linux.
      Quand une génération de chipset Qualcomm n’est plus récente, les ressources consacrées à la prise en charge dans le noyau mainline deviennent assez maigres. Aujourd’hui, il faut une énorme pression des fournisseurs pour faire bouger Qualcomm.
    • iwlwifi a aussi ses propres problèmes, le plus gros étant l’absence de mode point d’accès 5 GHz. La licence du firmware Intel est aussi plus restrictive que celle de MediaTek, et comme c’est du fullmac, le firmware prend beaucoup plus de choses en charge.
      Personnellement, je préfère le softmac. Il n’y a plus beaucoup de bons choix aujourd’hui, et l’âge d’or d’ath9k est passé.
    • Je me demande si tu les as vraiment utilisées, au-delà du simple « je ne fais pas confiance à MediaTek ».
      J’ai utilisé successivement un ThinkPad Intel et un ThinkPad AMD pour le travail, et le Wi-Fi avec chipset MediaTek côté AMD était nettement meilleur que le chipset Intel côté Intel.
      Côté Intel, la connexion réseau tombait plusieurs fois par heure, et même en 5 GHz la latence était horrible au point de se sentir immédiatement en SSH. L’appareil MT7921 que j’utilise actuellement est très stable sous Linux depuis 2 ou 3 ans.
      Au final, cela semble beaucoup dépendre de la combinaison chipset/ordinateur portable.

  • Si je me souviens bien, mon téléphone utilise aussi un chipset MediaTek. Et je me rappelle vaguement que la raison pour laquelle le fabricant s’est ensuite éloigné de MediaTek tenait à la, disons, qualité de ces produits.
    Je ne sais pas comment le Wi-Fi est organisé dans un téléphone. Y a-t-il un moyen de vérifier si ce téléphone est touché ? J’utilise très peu le Wi-Fi parce que j’ai des données cellulaires illimitées et une bonne couverture, mais ce serait quand même bon à savoir.

    • Dans termux, exécute "sudo su", puis regarde ls /sys/module.
      La sortie ressemble à celle de lsmod.

  • Même à une époque où les gens achètent n’importe quel silicium disponible, je ne comprends toujours pas pourquoi ces fournisseurs de série C ne suivent pas la stratégie du PC en ouvrant complètement leur firmware pour le confier à la communauté open source.

    • Les règles de la FCC, qui imposent généralement de rendre difficile l’émission en dehors des bandes autorisées, aboutissent souvent à ce genre de situation.

  • Il est écrit que « les versions touchées incluent MediaTek SDK 7.4.0.1 et antérieures ainsi qu’OpenWrt 19.07, 21.02 », et que « la vulnérabilité se trouve dans le démon réseau wappd inclus dans les bundles MediaTek MT7622/MT7915 SDK et de pilotes RTxxxx SoftAP », mais justement OpenWRT ne semble pas utiliser wappd.

    • En tant que contributeur OpenWrt, je me demande pourquoi les gens ne font pas la différence entre OpenWrt et un SDK fournisseur propriétaire. S’il y avait eu un bug dans Nobara, on n’aurait pas mentionné Fedora.
    • J’utilise OpenWRT sur plusieurs AP Netgear dans mon réseau domestique, donc je me posais la même question. D’après cette explication, je suis tranquille ?

  • C’est bien pour ça qu’il faut du firmware libre. J’en ai assez de Broadcom et Ralink.