Firmware Broadcom : Un bug wifi sur iPhone, mais pas que pour les utilisateurs Apple !

Plus tôt cette semaine, nous avions conseillé aux utilisateurs d’iPhone de ne pas tarder pour installer la dernière mise à jour iOS, et ce même si elle venait seulement cinq jours après la dernière mise à jour Apple, beaucoup plus importante.

NB : La mise à jour de la semaine précédente était un blockbuster de 700 Mo qui vous faisait passer à la version iOS 10.3. Cette semaine, il s’agissait de la version de maintenance 10.3.1 de 30 Mo.

Néanmoins, l’histoire derrière la mise à jour iPhone 10.3.1, va bien au-delà des iPhones, bien au-delà d’iOS, et même bien au-delà d’Apple.

Le bug qui a été corrigé dans iOS 10.3.1 a été trouvé et signalé par Gal Beniamini du Project Zero de Google, mais il ne s’agissait pas d’un bug dans iOS.

Certains des téléphones “vedettes” de Google ont également été touchés. En effet, Beniamini a utilisé un Nexus 6P comme cobaye pendant son immersion totale (et très intéressante) qu’il a réalisée lors de la recherche et de l’exploitation de cette faille.

Le bug ne se trouve pas dans le système d’exploitation principal lui-même, tel qu’Android ou iOS, ni sur l’une des applications installées, et il n’implique pas non plus l’exécution de programmes non autorisés au niveau du CPU de l’appareil.

Au lieu de cela, Beniamini a décidé de tester la sécurité des différents périphériques utilisés, bien à la périphérie de l’appareil.

Si vous considérez votre téléphone comme un ordinateur à part entière, tel qu’ordinateur portable par exemple, alors ce téléphone est lui-même connecté à un ensemble d’équipements auxiliaires, tels que des adaptateurs bluetooth, des webcams, des modems cellulaires et des cartes réseau Wi-Fi, qui peuvent être considérés comme des objets connectés (IoT).

Dans cette étude, Beniamini a décidé de se focaliser sur le matériel Wi-Fi Broadcom, mis en œuvre en tant que SoC, abréviation de “System on Chip“.

Ses motivations étaient simples : les équipements Broadcom sont largement utilisés, il pouvait donc obtenir la documentation technique facilement concernant les puces (certes, pas pour les versions les plus récentes). De plus, plusieurs appareils Google les utilisent, y compris les modèles Nexus 5, 6 et 6P, de sorte qu’il disposait aussi de cobayes pour ses essais, avec l’aimable autorisation de son employeur.

Et, comme il l’a dit lui-même :

Au fil des années, grâce au dur travail de la communauté cybersécurité, les protections des codes exécutés sur le processeur de l’application ont été renforcées [. . . ] Cependant, les cybercriminels ont tendance à suivre le chemin offrant le moins de résistance. L’amélioration de la sécurité d’un composant incitera inévitablement les cybercriminels à chercher ailleurs un point d’entrée plus facile.

Nous avons déjà vu ce type d’écart en matière de sécurité informatique lors de la comparaison des applications de bureau, telles que les navigateurs qui ont attiré l’attention pendant des années, avec les applications mobiles qui étaient quant à elles négligées.

Le pwning de votre Wi-Fi

Biniamini a trouvé plusieurs vulnérabilités dans le firmware Broadcom qu’il a choisi d’examiner, mais l’une d’elles a fait la une de l’actualité : CVE-2017-0561.

Ce bug est ce qu’on appelle une vulnérabilité de type débordement de pile (heap overflow), où la mémoire utilisée par une partie du logiciel empiète sur la mémoire utilisée par d’autre.

La pile (heap) est un terme issu du jargon, désignant une partie de la mémoire qui est géré par le système d’exploitation, avec des blocs à l’intérieur de cette pile, alloués temporairement à un processus à un moment donné, et libérés lorsqu’ils ne sont plus utilisés.

Sans une bonne gestion de la pile mémoire, chaque processus serait donc incité à récupérer le maximum de mémoire possible en anticipation de ses réels besoins, ce qui s’avérerait terriblement inefficace.

Si vous pouvez mettre en défaut la mémoire du processus de manière appropriée, vous pouvez organiser la façon avec laquelle le processus se mettra à mal fonctionner afin de prendre le contrôle sur la suite des opérations, comme le détournement du flux d’exécution du CPU vers les données présentes dans la mémoire tampon que vous venez de saturer.

Si vous pouvez faire cela, vous avez trouvé un exploit permettant l’exécution de code à distance (RCE) : sans vous connecter, saisir un mot de passe ou passer par une autre vérification de sécurité, vous pouvez alors prendre le contrôle et exécuter un morceau de code malveillant de votre choix.

Ces morceaux de codes malveillants sont connus dans le jargon sous le nom de shellcode, où le terme code signifie instructions de programme exécutable, et le terme shell est une métaphore qui provient de “command shell“, qui est le nom donné à une invite de commande dans le monde Unix.

Des opportunités manquées

Grâce à son exploration détaillée, Biniamini a découvert trois pratiques de sécurité informatique actuelles que le firmware Broadcom qu’il a analysé n’avait pas intégré.

La première opportunité manquée se nomme de plusieurs façons “heap cookies”, “heap canaries” ou “safe unlinking”.

Autrement dit, les systèmes d’exploitation modernes effectuent toutes sortes de contrôles supplémentaires lorsqu’ils attribuent et libèrent la pile mémoire, par exemple en plaçant une valeur de données choisie de manière aléatoire entre les blocs de mémoire distribués.

Ces vérifications ne stoppent pas les débordements de tampon, et n’empêchent pas qu’ils soient exploitables, mais elles rendent la tâche beaucoup plus difficile, et cela signifie que même si une attaque ne peut pas être complètement bloquée, elle peut souvent être détectée très rapidement et atténuée.

Chaque fois que le gestionnaire de mémoire du système est sollicité, il peut parcourir la liste des blocs de mémoire alloués pour rechercher une potentielle corruption, comme une preuve que le marqueur signalant la fin de chaque bloc n’a pas été endommagé, ce qui est presque inévitable dans le cas d’un débordement de mémoire tampon.

Le nom “heap canary” provient des canaris que les mineurs de charbon prenaient avec eux avant de descendre sous terre. En effet, un canari s’évanouissait en présence du gaz méthanique explosif et tombait ainsi de son perchoir, signalant que l’endroit était dangereux.

La deuxième opportunité manquée est appelée sur Windows Data Execution Prevention (DEP).

Cela signifie l’utilisation des fonctionnalités dans le CPU lui-même pour indiquer quelles parties de la mémoire contiennent des données plutôt que du code.

De cette façon, toute tentative, accidentelle ou délibérée, d’exécuter du code à partir d’un emplacement où des données étaient plutôt attendues, peut être détectée, signalée et bloquée.

La DEP rend le débordement de pile plus difficile à exploiter parce que vous ne pouvez pas simplement insérer les octets shellcode dans votre débordement de tampon et court-circuiter le CPU, car ce dernier sait que la pile contient des données et n’autorisera aucune exécution.

Et même si le CPU présent dans le matériel Broadcom Wi-Fi affecté est très dépouillé (c’est un ARM Cortex R4), il possède néanmoins une unité de protection mémoire ou MPU (Memory Protection Unit).

Vous pouvez configurer le Cortex R4 afin que votre mémoire disponible soit divisée en 12 régions différentes, chacune avec ses propres paramètres de contrôle d’accès.

Vous pouvez donc verrouiller le code de sorte qu’il soit exécutable mais pas accessible en écriture, empêchant ainsi qu’il soit modifié de façon inattendue. Vous pouvez aussi verrouiller les données telles que la pile, de sorte qu’elle soit accessible en écriture, mais pas exécutable, empêchant l’exécution d’un shellcode.

Biniamini a découvert que le firmware Broadcom avait soigneusement divisé l’espace d’adressage de 4 Go (tout l’espace d’adressage ne doit pas être rempli avec de la RAM ou de la ROM), comme ceci :

Address range            Access control options
-----------------------  ------------------------------
0x00000000 - 0x0FFFFFFF  Readable, Writable, Executable
0x10000000 - 0x1FFFFFFF  Readable, Writable, Executable 
0x20000000 - 0x3FFFFFFF  Readable, Writable, Executable 
0x40000000 - 0x7FFFFFFF  Readable, Writable, Executable 
0x80000000 - 0xFFFFFFFF  Readable, Writable, Executable

En d’autres termes, le firmware Broadcom a eu du mal à configurer le MPU, sans en bénéficier : la mémoire a été divisée en cinq zones ouvertes à tous.

NB : Apparemment, le nouveau firmware Broadcom Wi-Fi utilise mieux le MPU, signifiant que ce problème disparaîtra au fur et à mesure que les anciens périphériques seront remplacés ou mis à jour.

La troisième opportunité manquée est l’ASLR (Address Space Layout Randomization), ou encore la structure aléatoire de l’espace d’adressage, au niveau duquel votre code et ses données associées se retrouvent chaque fois dans différentes adresses mémoire.

Le firmware Broadcom Wi-Fi SoC n’est pas stocké sur la puce elle-même. À la place, l’ordinateur principal installe une copie du firmware Broadcom chaque fois que la puce Wi-Fi est redémarrée, et généralement lorsque le périphérique hôte est lui-même désactivé et réactivé.

En réarrangeant la structure du firmware à chaque fois, même légèrement, vous créez une cible beaucoup moins prévisible pour un éventuel cybercriminel.

Par exemple, dans le code de Biniamini ayant servi de “preuve de concept”, et montrant comment rechercher et exploiter cette faille, il utilise de nombreux emplacements pour découvrir à quels endroits de la mémoire certains codes et certaines données seront disponibles, en utilisant différentes adresses physiques pour différentes versions du firmware Broadcom.

Le fait de rendre la cartographie mémoire du firmware différente au niveau de chaque périphérique, en la rendant aléatoire à chaque fois que l’appareil démarre, signifie aussi qu’un cybercriminel ne pourra pas non plus s’appuyer sur ces adresses connues.

Une fois encore, l’ASLR ne rend pas impossible les exploits permettant l’exécution de code à distance. En effet, si par exemple une partie du système fournie accidentellement la cartographie mémoire actuellement utilisée, et une autre partie contient une faille potentiellement exploitable et permettant l’exécution de code à distance, alors les deux vulnérabilités peuvent être combinées pour former un exploit opérationnel.

Mais l’ASLR combiné à la DEP rend le travail beaucoup plus difficile pour les cybercriminels.

Bien sûr, pour être juste envers Broadcom, et pour autant que le bug soit réellement dans le code de Broadcom, cette histoire ne s’arrête pas là !

En effet, Google, Apple et d’autres qui ont choisi d’utiliser le hardware et le firmware Broadcom affectés au sein de leur propre appareil doivent aussi accepter leur part de responsabilité.

Ceci est particulièrement vrai dans le cas de périphériques verrouillés comme les iPhones, où vous ne pouvez pas appliquer vos propres mises à jour, même si vous le souhaitez : le firmware buggé est chargé à partir du système de fichiers du périphérique hôte, donc seul l’éditeur peut installer la mise à jour pour vous.

Quoi faire ?

Cet exploit RCE peut, en théorie, être déclenché par n’importe quel périphérique connecté au même réseau Wi-Fi que vous, mais il ne pourra pas entrer directement dans votre appareil : les cybercriminels resteront encore à la périphérie.

Néanmoins, nous pensons que c’est un problème d’avoir un firmware Wi-Fi exploitable, notamment parce que toutes vos données Wi-Fi entrantes et sortantes y sont stockées, c’est pourquoi nous vous recommandons de corriger ce bug sur votre iPhone dès que possible !

Ce qui est délicat dans ce cas, c’est de savoir exactement quels périphériques sont en danger : les iPhones récents ont déjà été corrigés, ainsi que certains téléphones Google Nexus et Pixel, mais nous ne pouvons pas vous donner une liste d’autres périphériques susceptibles d’être affectés.

Le problème est que ce bug particulier et les correctifs actuels sont plus un exemple et un symptôme qu’un correctif global.

Nous savons qu’un équipement Broadcom Wi-Fi SoC en particulier, fonctionnant avec une version originale du firmware Broadcom est clairement affectée, et contient l’un des bugs que Biniamini a trouvés, car il a justement publié une preuve de concept pour le démontrer.

Mais nous savons aussi que Biniamini a trouvé le même type de problème “sans DEP” sur un Nexus 5, qui n’a pas encore reçu de patch de Google. Nous pouvons deviner que le code simplifié de gestion de la pile peut également se trouver dans d’autres firmwares de Broadcom largement répandus, et nous pouvons supposer que certains équipements Broadcom SoCs de la même période n’utilisent pas non plus l’ASLR.

Pire encore, Google déclare qu’il a un deuxième volet à cette histoire, un piratage par lequel un cybercriminel peut “basculer” au niveau de la puce Wi-Fi pour exécuter le code sur le périphérique hôte lui-même, mais l’entreprise n’a pas encore publié cette partie.

En d’autres termes, ce bug est potentiellement sérieux, mais dans la vraie vie, il est inutile de trop s’inquiéter en raison du nombre inconnu de combinaisons possibles entre hardware, firmware, périphériques hôtes et systèmes d’exploitation, et susceptibles d’être réellement affectés.

Cependant, si vous êtes vraiment inquiets :

• Utilisez uniquement les connexions 3G/4G et désactivez le Wi-Fi lorsque vous êtes en itinérance.
• Éteignez et redémarrez votre appareil de temps en temps, ce qui recharge le firmware Wi-Fi (L’exploit de Biniamini corrige le firmware temporairement dans la mémoire, mais pas constamment sur le disque de l’appareil hôte).
• Demandez à votre éditeur ou fournisseur davantage d’informations, et installez les mises à jour dès que possible.

Follow @ SophosFrance //platform.twitter.com/widgets.js
Billet inspiré de That ‘iPhone Wi-Fi bug’ isn’t just for Apple users – here’s a rundown, par Paul Ducklin, Sophos NakedSecurity.