Meltdown et Spectre : impact des bogues de processeur sur la sécurité de l'IoT

Introduction

La sécurité des systèmes est généralement considérée comme un sujet concernant uniquement les domaines des technologies de l'information, que ce soit au niveau de l'entreprise en général ou des postes de travail en particulier, et elle n'est pas souvent prise au sérieux dans la sphère intégrée. Cela est en train de changer rapidement, en raison de l'explosion de l'Internet des Objets (IoT) et de l'importance croissante des systèmes intégrés dans les applications critiques pour la sécurité. Cette constatation a été soulignée l'année dernière, avec le logiciel malveillant Mirai qui a infecté des enregistreurs vidéo numériques et d'autres périphériques de niveau inférieur, mais connectés à Internet. Mirai n'a pas fait cela pour viser le moindre aspect de leurs fonctionnalités, qui ont continué de fonctionner sans entrave, mais tout d'abord pour identifier et infecter d'autres périphériques, puis pour utiliser une grande quantité d'appareils infectés comme rampes de lancement pour des attaques par déni de service distribué qui ont fermé ou ralenti radicalement des sites Web hôtes. Puisque bon nombre de ces enregistreurs, comme leurs caméras associées, faisaient souvent partie de systèmes de sécurité, il ne faut pas beaucoup d'imagination pour comprendre que le fait de les infecter aurait pu être utilisé à d'autres fins. Mirai s'est propagé, et des variantes continuent de se développer, car des millions de périphériques sont expédiés avec des paramètres de sécurité par défaut qui constituent une porte ouverte à la curiosité des logiciels malveillants.

Alors que Mirai a utilisé Internet et le protocole Internet pour pénétrer dans les périphériques ciblés, d'autres canaux de communication peuvent également être utilisés, tels que le Bluetooth. Armis, qui se spécialise dans la sécurité de l'IoT, a identifié huit vulnérabilités parmi les piles Bluetooth qui prennent en charge les communications dans de nombreux équipements mobiles. Ils les appellent les BlueBorne et elles font l'objet d'une discussion dans un autre document sur la sécurité de l'IoT « la lutte s'intensifie entre Bluetooth et les pirates ».

Il est de plus en plus évident que les pirates ne sont plus seulement des jeunes gens désœuvrés opérant depuis leur chambre, mais des groupes organisés disposant d'un savoir faire technique considérable. Certains de ces groupes peuvent être criminels, tandis que d'autres sont des entités nationales ; il est bien connu que la Russie utilise un vaste éventail d'armes cybernétiques contre l'Ukraine, avec notamment la neutralisation du réseau de transmission électrique. Une grande partie du travail s'est concentrée sur les faiblesses des logiciels et sur les fragilités humaines. Mais ces groupes organisés tournent leur attention vers l'IoT et l'Internet des objets industriel, où la collecte et la transmission de données, souvent sans aucune intervention humaine, peuvent fournir des informations précieuses sur les activités d'un organisme, afin de les exploiter à des fins vénales, ou de les corrompre pour provoquer de graves dommages. Ces dommages peuvent être physiques, en faisant fonctionner les équipements au-delà de leurs possibilités, et financières, en perturbant les opérations des organisations.

Et c'est ce qui rend la découverte de ces deux vulnérabilités matérielles, Meltdown et Spectre, particulièrement inquiétante.

Meltdown et Spectre

Qu'est-ce que Meltdown et Spectre ?

La plupart des problèmes de sécurité auxquels les organisations doivent faire face aujourd'hui sont dus à l'exploitation des failles logicielles d'un système. Il existe également des méthodes d'attaque qui utilisent les informations recueillies à partir de l'implémentation physique d'un système. Ces attaques par des canaux secondaires recueillent, par exemple, des informations de temps, de consommation électrique ou de fuites électromagnétiques pour mieux comprendre ce que le système exploré est en train de faire. Meltdown et Spectre vont encore plus loin en exploitant des aspects liés à la conception des processeurs hautes performances pour accéder aux informations sur les applications en cours d'exécution. Ces caractéristiques de conception sont utilisées dans de nombreux processeurs modernes Intel et AMD et dans les cœurs Arm, et concernent la mise en cache et l'exécution spéculative.

Un pseudo-programme simple pourrait être :

• t = a+b
• u = c+d
• v = e+f
• w = v+g
• x = h+i
• y = j+k

Dans une conception informatique classique, un processeur scalaire, comme Intel 486 et Arm 1176, va exécuter une instruction pour chaque cycle de l'horloge du système. Ces six instructions vont occuper six cycles d'horloge.

Pour augmenter les performances d'un tel système, il suffit d'augmenter la vitesse de l'horloge. Cependant, cela donne lieu à deux problèmes. Le premier est essentiellement lié au fait qu'il existe une limite à la vitesse d'exécution des portes logiques, et deuxièmement, les vitesses de lecture et d'écriture de la mémoire sont de plus en plus lentes par rapport aux vitesses des processeurs. Une alternative à l'augmentation de la vitesse d'horloge du processeur consiste à tenter d'exécuter plusieurs instructions à la fois, et de créer ainsi un processeur superscalaire. Si nous avions un processeur à deux chaînes de traitement, il exécuterait deux instructions en même temps. Le même pseudo-code serait donc :

• t, u = a+b, c+d
• v, w = e+f, v+g
• x, y = h+i, j+k

Et, en théorie, le temps d'exécution serait réduit de moitié

L'examen du code révèle un problème. La seconde paire d'instructions ne peut pas être exécutée simultanément car v doit être terminé avant de pouvoir exécuter w. La chaîne d'instructions 2 doit attendre que la chaîne 1 soit terminée, comme cela :

• t, u = a+b, c+d
• v = e+f            # la seconde chaîne ne fait rien ici
• w, x = v+g, h+i
• y = j+k

Cela se traduit par quatre cycles d'horloge au lieu de trois, ce qui reste une amélioration.

Mais comme la seule dépendance est entre w et v, nous pourrions rétablir l'ordre des instructions en inversant w et x et cela nous donnerait :

• t, u = a+b, c+d
• v, x = e+f, h+i
• w, y = v+g, j+k

C'est la meilleure solution à trois instructions que nous obtenons avec deux chaînes. Les processeurs superscalaires à exécution dans le désordre sont par exemple la plupart des processeurs Intel et AMD x86 à partir de Pentium 2, et les cœurs Arm les plus récents.

Dans la réalité, les programmes sont plus complexes que notre petit exemple. La plus grande différence réside dans le fait qu'ils incorporent des branchements. Ceux-ci peuvent être inconditionnels (toujours pris) ou conditionnels (selon une valeur calculée). Ils peuvent être vers l'avant (en cas d'énoncés) ou vers l'arrière (boucles). Ils peuvent être directs, vers une adresse cible spécifique, ou indirects à l'aide d'une adresse à partir d'un registre, d'un emplacement de mémoire ou de la pile du processeur.

Afin que l'exécution ne s'interrompe pas au niveau des branchements, les transformateurs font appel à des prédicteurs de branchement qui utilisent les statistiques des branchements précédents, afin d'essayer de prédire l'état des branchements. Des techniques spéculatives peuvent également être utilisées en présence de pipe-lines triples ou quadruples. Il s'agit dans ce cas de deviner quelles instructions seront nécessaires, puis de les exécuter. Si elles ne sont pas utilisées, un branchement les a peut-être rendues superflues ; le résultat est alors rejeté. En s'appuyant sur les chemins renvoyés par le prédicteur de branchements, la spéculation portant sur les instructions peut accélérer de façon notable l'exécution du programme.

Mais comme nous l'avons dit plus tôt, la mémoire ne parvient pas à suivre la vitesse d'exécution. Pour contourner ce problème, les concepteurs de processeurs utilisent des caches, à savoir de petites mémoires pour des sous-ensembles de mémoire placés directement sur la puce du processeur. Ceci permettra de conserver des copies des emplacements de la mémoire principale ayant eu des accès récents ou qui sont situés à proximité d'un emplacement déjà sollicité, car ce sont les plus susceptibles d'être bientôt requis.

Avec ces outils, un attaquant peut exploiter deux choses. La première est le fait que le prédicteur de branchement puisse être formé pour réaliser de mauvaises prévisions. Et en mesurant le temps d'un accès mémoire, on peut voir si l'adresse se trouvait dans le cache ou non.

À l'aide de ces informations, un attaquant utilisant Meltdown est capable de lire les informations stockées dans le noyau du système d'exploitation, tandis qu'avec Spectre, il peut lire la zone mémoire d'autres programmes en cours d'exécution qui devraient pourtant être inaccessibles.

Figure 1. La séquence d'instructions de base de Meltdown

Pour pénétrer dans le matériel ciblé, les attaques pourraient utiliser un court programme JavaScript. Dans le cas de systèmes exploitant un navigateur Web (tel qu'un téléphone cellulaire ou une tablette) cela peut se faire en exécutant une page Web infectée. D'autres périphériques, comme des points d'extrémité IoT, peuvent être attaqués par le logiciel malveillant parcourant le Web à la recherche d'appareils mal protégés, soit la même approche que celle utilisée par Mirai. Une fois qu'une attaque par Meltdown ou Spectre a eu lieu, il n'y a pas de preuves tangibles dans le système atteint.

Malgré l'énorme couverture médiatique et toutes les discussions autour de cette menace, il n'y a eu aucun cas recensé de Meltdown ni de Spectre.

Qui est touché ?

Meltfown est principalement un problème sur les processeurs Intel. Tout processeur Intel fabriqué après 1995 est vulnérable, à l'exception d'Itanium et de certains processeurs Atom. Arm a également signalé que le cœur Cortex A-75 était vulnérable. En dehors du monde intégré, Apple a signalé que la plupart de ses produits étaient vulnérables et a sorti des mises à jour des systèmes d'exploitation pour l'ensemble de sa gamme.

Spectre est plus répandu, de nombreux processeurs Intel et AMD étant vulnérables. Les cœurs Arm Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73 et Cortex-A75 sont tous vulnérables. Si on rencontre ces cœurs dans de nombreux processeurs, la famille de cœurs la plus populaire en utilisation intégrée et IoT est la série Cortex M, qui n'est pas vulnérable. D'autre part, Arm souligne que les cœurs Cortex-R sont principalement utilisés dans des systèmes fermés, où il n'y a souvent aucune interface utilisable pour une attaque.

Raspberry Pi n'utilise aucun des cœurs vulnérables (Raspberry Pi 3 et les Raspberry Pi 2 récents utilisent Broadcom BCM2837, qui est équipé de l'ARM Cortex-A53) et n'est pas menacé par Spectre et Meltdown.

Au vu de l'étendue des cartes qui sont disponibles, la situation est moins claire. La sélection de la carte consistant à proposer des performances et des fonctionnalités adaptées aux besoins de l'application, ces critères continueront à être primordiaux. Mais les développeurs pourraient préférer choisir une carte qui est moins exposée à ces menaces, plutôt que d'essayer d'utiliser certaines des mesures disponibles pour en atténuer les effets.

Atténuation

Depuis la parution des premiers rapports, on a assisté à une myriade d'éventuelles mesures d'atténuation, de la part des fabricants de puces et d'Arm, ainsi que des développeurs des systèmes d'exploitation. Les principaux fournisseurs de systèmes d'exploitation ont publié des mises à jour qui proposent quelques progrès en matière d'atténuation, à défaut de mettre un terme à ces attaques. Les spécialistes de la lutte contre les logiciels malveillants ont aussi apporté des mises à jour de leurs produits susceptibles de contribuer à arrêter les actions qui déclenchent les attaques.

Les fabricants ont également émis divers correctifs possibles pour leur microcode, mais le problème est que Meltdown et Spectre exploitent les décisions de conception qui visent à accélérer les performances du système, et les mesures d'atténuation ont pour effet de ralentir le processeur. Selon un premier commentaire de la presse, cette baisse de performance pourrait être importante et atteindre 25 %. Cela a été révisé à la baisse, mais la situation est confuse, car Intel doit retirer ses mises à jour de microcode et introduire une série de mises à jour ciblant les différentes familles de processeurs. Toutefois, lors de la rédaction du présent document, aucune estimation de performance n'est disponible. L'autre problème est que de nombreux commentateurs et testeurs qui travaillent sur ce sujet sont des spécialistes des ordinateurs et des technologies de l'information, et ne mesurent pas l'impact sur les systèmes intégrés.

Quelques correctifs d'Arm sont liés au système d'exploitation. Encore une fois, on ne connaît pas l'incidence de l'application de ces correctifs sur la performance.

Les produits intégrés travaillent souvent en temps réel, et, encore une fois, lors de la rédaction les fournisseurs RTOS n'ont pas fait de commentaires, sauf l'un d'entre eux qui déclare que RTOS n'est pas concerné par ce problème. Les développeurs de produits intégrés choisissent souvent un processeur selon l'équilibre puissance/performance et spécifient un processeur aussi proche que possible de la cadence nécessaire. La moindre baisse de performance peut potentiellement provoquer une défaillance de l'application.

Que devraient faire les ingénieurs en IoT ?

Dans le contexte de l'IoT, de façon simpliste, il y a plusieurs points à considérer. Les appareils en périphérie, où l'information est recueillie et les appareils sont contrôlés ; la passerelle, qui recueille les flux à partir de plusieurs appareils et les transmet au réseau ; les processeurs réseau et enfin, les serveurs dans le Cloud. Pour les serveurs, les entreprises comme Amazon travaillent d'arrache-pied pour renforcer davantage l'isolation entre différents utilisateurs et pour améliorer d'autres mesures de sécurité. Dans l'ensemble, les processeurs réseau Ethernet ne sont pas touchés par Meltdown et Spectre. Les systèmes de passerelle sont potentiellement à risque et une grande partie des informations concernant les appareils de périphérie s'appliquent également aux passerelles.

En ce qui concerne la périphérie de l'IoT, il y a deux problématiques. D'un côté, les produits déjà déployés et, de l'autre, les futurs produits.

De nombreux produits existants de l'IoT utilisent des processeurs d'entrée de gamme, les cœurs Cortex-M. Ceux-ci ne présentent de risque d'attaque ni d'un côté ni de l'autre. Quel que soit le processeur, il serait judicieux de procéder à une vérification de tous les produits déployés et d'évaluer leur vulnérabilité, y compris les risques d'attaque, et d'envisager la nécessité ou pas de publier des correctifs. Il est également fortement recommandé de mettre en place une stratégie d'entreprise pour faire face aux questions de sécurité à venir, car il est presque certain qu'elles surviendront au niveau des processeurs, de la puce de communications ou bien du produit IoT lui-même.

Pour les nouveaux produits, les mesures de sécurité doivent être comprises dans les critères de conception. (L'étude de 2018 de Barr Group démontre que moins de 22 % des Projets IoT comportaient des exigences de sécurité en 2017.) Et depuis, même avec tout le soin accordé à la conception et à la mise en œuvre, il y aura toujours d'autres problèmes, par conséquent les critères de conception doivent intégrer des dispositions pour des palliatifs potentiels et des correctifs sur site.

Les correctifs sur site des logiciels étant onéreux, et la fourniture de cartes de remplacement revenant encore plus cher, il est bien plus avantageux de consacrer plus de temps et d'énergie à la construction de systèmes robustes et sécurisés. Les plus petites choses, comme le fait de lier la première utilisation du système au changement des mots de passe d'usine, permettent de limiter la vulnérabilité. (Et il ne faut que quelques lignes de code pour arrêter de commettre les erreurs les plus communes, comme les mots de passe du type 123456 ou asdgfg.) Examinez attentivement les accès nécessaires et les sections concernées du système. Vous pouvez peut-être disposer de plusieurs niveaux de sécurité pour des tâches différentes.

Pour le moment, jusqu'à la sortie de processeurs vulnérables équipés de micrologiciels capables de stopper Meltdown ou Spectre, étudiez d'autres possibilités. Ayez recours à de bonnes pratiques de programmation et à des outils permettant de développer un code de bonne qualité. Et enfin, attendez-vous à l'émergence d'un nouveau problème dans peu de temps.

Meltdown et Spectre : l'impact des bogues de processeur sur la sécurité de l'IoT. Publié le 15 mars 2018 par Farnell