Dans les systèmes électroniques et informatiques, un micrologiciel (firmware en anglais) est considéré comme étant l'association de code exécutable et des données stockées à l'intérieur. Un logiciel embarqué est un logiciel réalisé pour contrôles des périphériques ou appareils, qui ne sont généralement pas considérés comme étant des ordinateurs à part entière. Ils sont particulièrement utilisés au sein de matériels fonctionnant avec de hautes contraintes temps et mémoire. Cet article décrit les vulnérabilités des micrologiciels et leurs contre-mesures.

Introduction aux micrologiciels La vulnérabilité des micrologiciels est une problématique ascendante et évolutive liée à la sécurité des systèmes embarqués et informatiques en général. Ces vulnérabilités sont exploitables et peuvent en l’absence de tout correctif (Mise à jour) être la voie d’attaque des systèmes embarquant des micrologiciels. Plusieurs innovations technologiques issues du domaine de la recherche ont permis des progrès dans la sécurité des micrologiciels. Ces contremesures bien que fiables ne sont dans certains cas pas perennes à cause de la technologie et des failles qui sont évolutives.

Définitions Une vulnérabilité se réfère à toute chose qui par ses insuffisances, ses imperfections, peut donner prise à des attaques, Larousse. La notion de vulnérabilité peut être également perçue comme un ensemble de sensibilités d'un dispositif aux blessures, aux attaques ou son incapacité (difficulté) à se maintenir fonctionnel face à sa mise en péril par autrui , Jean-Claude Thouret, 1996, Pages 407-422.

Un micrologiciel, aussi appelé “firmware”, microprogramme et même logiciel embarqué, est intégré dans des systèmes matériels. Les micrologiciels sont davantage présents dans la plupart des équipements que nous utilisons, ordinateurs, voitures, portables, imprimantes, réfrigérateurs. Il existe plusieurs types de micrologiciels. Ce sont des programmes en mémoire et en lecture seule, CURRY, Stephen M., FOX, Christopher W., et LOOMIS, Donald W, U.S. Patent No 6,105,013, 15 août 2000, .

La vulnérabilité des micrologiciels nous renvoie sur la vulnérabilité de tout système informatique. Celle-ci est spécifique à l’ensemble des failles et bugs que contiennent les micrologiciels en l’absence de tout correctif et qui peuvent malencontreusement être exploitées pour des attaques. Les micrologiciels des systèmes autonomes ou non peuvent donc être sujet à de nombreuses attaques dues à de nombreuses failles. On met l’accent ici sur toutes les éventuelles failles connues ou non et qui sont exploitables dans le but de contrôler, rendre vulnérable, ou mettre en péril le bon fonctionnement du système, Global Security Mag, Kaspersky Lab, juillet 2011.

Problématique de la vulnérabilité d’un micrologiciel

La problématique de la sécurité n’est pas spécifique aux systèmes informatiques usuels destinés aux utilisateurs finaux, mais à l'ensemble des systèmes informatiques embarqués qui aujourd’hui font face à de nombreux défis en matière de sécurité. Un micrologiciel est généralement un microprogramme informatique spécifique et codé dans un langage de données. Il est connu que certaines erreurs de programmations dans certains langages se révèlent être la source de nombreuses vulnérabilités, donc point de départ des attaques. Cette assertion n’épargne pas les micrologiciels, même s’ils sont dans des systèmes embarqués , Laurent Butti, France Télécom R&D Laboratoire Séecurité des Services et Réseaux, Actes du symposium SSTIC07, 2007 p2. De manière intrinsèque, les micrologiciels sont donc susceptibles de présenter les erreurs de programmations (vulnérabilités) qui peuvent être sources d’attaques.

Bien qu'il soit possible de désosser le micrologiciel, de supprimer certaines limitations, ces types d’attaques nécessitent de considérables efforts à mettre en œuvre. Plusieurs mécanismes alternatifs pour contourner les limitations imposées par l'interface du micrologiciel sont connus. Pour comprendre notre approche, il est d'abord nécessaire de comprendre son architecture. L’exemple ci-dessous nous présente un micrologiciel 802.11.

Ces dernières années, plusieurs chercheurs ont examiné la sécurité des micrologiciels ainsi que divers dispositifs, tels que les bandes de base, cartes, chipsets, etc. Les vulnérabilités dans ces composants embarquant les micrologiciels sont sujets à des attaques qui pourraient permettre à un intrus de prendre le contrôle total de la composante et l'utiliser comme un tremplin pour lancer d'autres attaques contre d'autres systèmes d'exploitation ou d'autres périphériquesLoic Duflot, « Contribution à la sécurité des systèmes d’exploitation et des microprocesseurs ».

Architecture et caractéristiques, diversité des micrologiciels

Plusieurs architectures sont connues en fonction du champ d’application du micrologiciel, en partant des ordinateurs ou des équipements de grande utilité, mais aussi en fonction du type de micrologiciel. Les différentes architectures de micrologiciels sont basées sur des bus entrées-sorties. Il est donc opportun de préciser qu’il n’existe pas d’architecture standard ni de modèle figé d’architecture pour les micrologiciels.

Les micrologiciels, comme l’ensemble des systèmes à mémoire se caractérisent généralement par la taille mémoire qui induit le temps de flashage, le flux de transfert et la méthode de mise à jour. Les micrologiciels peuvent être classés en deux grandes familles. Nous avons les type “binaire”: compressés ou non et de type archive , Hongfei Yin, 2011 IEEE, . thumb|267x267px

Dans les systèmes embarqués, le micrologiciel est généralement organisé comme représenté sur la figure ci-dessus. Au cours du processus de démarrage, le chargeur de démarrage est maintenu, il peut être amorcé en premier lieu lorsque le système est sous tension et ensuite le noyau de l'OS suit de près.

Comme le bootloader fonctionne tout d'abord, il initialise le matériel nécessaire et prépare les environnements logiciels de fonctionnement. Dans les détails, le bootloader divise processus de chargement en deux parties. L’étape 1 est étroitement liée au matériel.

Dans l'espace restant, les programmes d'applications sont stockés et généralement organisés par le système de fichiers et la mémoire vive John Bellardo,12th USENIX Security Symposium, August 4–8, 2003, Washington, DC, USA, . Avant de démarrer l'étape 2, il vérifie habituellement un premier code de chargé par le matériel selon le processus de démarrage décrit.

Ensuite, l'étape 2 est chargée et démarrée. Cette étape permet de lancer les fonctions plus sophistiquées. Il initialise les différents besoins pour le matériel (ports, les entrées et les sorties). Il va ensuite charger et démarrer le noyau du système chargé de la gestion des ressources du système, tels que les différents processus, la gestion de la mémoire. Ainsi, le système est démarré et les programmes d'application peuvent fonctionner sur la base de ceux-ci: valeurs d'initialisation.

De toute évidence, cette architecture de micrologiciel est très fragile, parce qu'elle ne garantit pas la fiabilité de n'importe quelle étape des différents processus.

Intérêt et motivations des attaques de micrologiciels

Les attaquants de micrologiciels, utilisent généralement les failles d’implémentation pour nuire au système. Même si c’est la première appréhension qu’on a du concept des attaques, il faut reconnaitre qu’ils permettent d’évaluer, la sécurité et la robustesse des systèmes embarqués. Bien que la finalité d’une attaque soit de mettre hors d’état de service le système embarquant le micrologiciel, il faudrait sous un autre angle voir des intérêts économiques, stratégiques et même politique.

Exemples d’attaques sur architecture x86

System Management Mode

Description

Le SMM (System Management Mode) est le mode d’exécution des processeurs x86 et x64 le plus privilégié. Lorsque le processeur est dans ce mode, l’exécution normale du CPU est suspendue pour laisser la main généralement à un micrologiciel ou à un débogueur matériel. Le SMM est un mode 16-bit qui est utilisé pour des applications telles que la gestion de la température ou de l'énergie (ex. : ACPI). Il est possible d'entrer dans ce mode uniquement lors de la réception d'une SMI (générées par le Northbridge ou lors de l'écriture du registre AMPC). Une zone mémoire spéciale appelée SMRAM permet de sauvegarder le contexte du CPU lors du basculement dans le SMM. À la réception d'une SMI, et donc au moment du basculement en SMM, un handler SMI sera exécuté depuis la SMRAM. La SMRAM est située dans la RAM mais n'est pas accessible par le CPU en raison du verrou D_OPEN du chipset. Ainsi, même en ring0, le CPU ne peut pas constater l'existence des handlers SMI ou même remarquer l'interruption de l'exécution normale du CPU.

Protections de la SMRAM Le code exécuté en SMM ayant encore plus de privilèges que le mode ring0, il est nécessaire de le protéger. La position de la SMRAM est indiquée par le registre SMBASE qui ne peut être accédé qu'en SMM. La SMRAM ne peut être accédée depuis les autres modes CPU sauf si le verrou D_OPEN est ouvert. Pour empêcher la modification du code des handlers de SMI, il existe également un verrou D_LCK qui met la SMRAM en lecture seule.

Contournement du verrou D_LCK Afin de permettre la corruption de la SMRAM malgré le verrou D_LCK, certaines recherches ont illustré des techniques de contournement de ce verrou. Par exemple, il existe des techniques d'empoisonnement de cache ou d'attaque de l' du chipset AGP Attaque via l'ouverture graphique Loïc Duflot a montré comment utiliser les mécanismes d'ouverture graphique pour contourner D_LCK. L'ouverture graphique d'AGP est une zone de l'espace des adresses physiques utilisée pour une communication rapide, via DMA, entre le contrôleur graphique (ex: serveur X) et le GPU. Étant donné qu'il est pas certain qu'on puisse avoir une zone contigüe de mémoire physique disponible pour cette ouverture graphique, un mécanisme de traduction d'adresse existe au sein du chipset (à ne pas confondre avec la qui se situe entre le CPU et le northbridge). Grâce à ce mécanisme, il est possible d'avoir l'impression qu'une zone de l'espace physique est disponible. Le problème montré est qu'il est possible, depuis une application utilisateur disposant des privilèges d'entrées-sorties, de modifier les registres de configuration de l'ouverture graphique. Ceux-ci permettent notamment de positionner de manière arbitraire l'ouverture et de spécifier l'adresse de la table de traduction. Ainsi, on pourra positionner l'ouverture graphique sur une zone critique d'une noyau (ex: GDT) pour la rediriger vers une partie de la mémoire physique correspondant à de la mémoire que l'on contrôle. Attaque par empoisonnement du cache CPU SMRAM et mise en cache