La panne mondiale provoquée le 25 juillet par une mise à jour fautive du logiciel de l’entreprise CrowdStrike [1] aura causé des dommages considérables dans le monde entier, dégâts estimés à un nombre encore inconnu de milliards de dollars.

Cette panne n’a rien à voir avec le micro-logiciel de nos ordinateurs (le BIOS), mais l’attention attirée sur les questions de sécurité donne l’occasion d’explications sur un sujet trop ignoré.

Sous le système, le micro-logiciel

Tout au long de cet ouvrage nous avons décrit le fonctionnement du système d’exploitation, ainsi que celui du matériel informatique et du réseau dans la mesure où cela était nécessaire pour comprendre le système. Mais il existe un autre élément moins visible mais tout aussi nécessaire au fonctionnement de l’ordinateur, le micrologiciel (firmware en anglais). À l’origine des temps (années 1970) c’était le BIOS (Basic Input/Output System), qui s’est perfectionné pour devenir UEFI (Unified Extensible Firmware Interface), implanté dans un composant électronique distinct du processeur, branché sur la carte-mère.

À partir de 2008 Intel a introduit Intel Management Engine, dont un composant est Intel Active Management Technology (AMT, les autres industriels tels AMD et ARM disposent de technologies équivalentes) ; il s’agit en fait d’un ordinateur complet, implanté dans un composant électronique distinct, avec un véritable système d’exploitation, qui supervise tout le fonctionnement de l’ordinateur, notamment du point de vue de la sécurité. Nous allons examiner ces dispositifs.

Dispositif d’amorçage du système

Tous les ordinateurs contemporains utilisent pour effectuer leur première phase de démarrage (ou amorçage) un logiciel assez particulier généralement intitulé BIOS (Basic Input/Output System). Le BIOS a été inventé en 1975 par Gary Kildall pour son système d’exploitation CP/M.

Le BIOS est enregistré dans un élément de mémoire non-volatile physiquement distinct des autres composants de la carte mère de l’ordinateur ; depuis les années 1990 c’est en général de la mémoire Flash, analogue à celle des clés USB et des disques SSD, ce qui permet de le modifier, et ce qui introduit par conséquent un risque de modification malveillante. La carte mère et le processeur sont configurés de sorte qu’à la mise sous tension ce programme soit chargé dans la mémoire vive et commence son exécution. L’action de ce programme consiste essentiellement à aller chercher sur une mémoire externe (disque dur, clé USB...) préparée à cet effet un autre programme un peu moins petit, à le recopier en mémoire centrale et à en déclencher l’exécution. Ce processus est connu sous le nom de boot-strap ou simplement boot, mais il est permis de dire amorçage. C’est ce programme de boot qui va charger en mémoire le noyau du système d’exploitation, éventuellement à partir d’un serveur de boot sur le réseau. Afin de simplifier les opérations du BIOS (rappelons-nous que ces mécanismes avaient été conçus en des temps de processeurs lents et de mémoire de faible capacité), le programme de boot était le plus souvent enregistré dans le premier secteur du premier disque visible sur le bus [2]. Ce secteur contenait aussi la table des partitions « ancien style » du disque, il est nommé Master Boot Record (MBR). Nous allons voir que les systèmes plus modernes avec des mémoires et des disques plus spacieux n’utilisent plus vraiment le MBR (sauf s’ils comportent toujours un BIOS pour pouvoir démarrer à partir de supports à l’ancienne mode tels que cédéroms), mais que la table des partitions et le logiciel d’amorçage occupent des espaces plus vastes ailleurs sur le disque.

Lors du lancement en 1981 du PC, IBM en a publié toutes les spécifications techniques, et notamment celles de la version simplifiée du BIOS qu’ils avaient adoptée (avec le code source !). Ce BIOS était à l’échelle des capacités des mémoires et des disques de l’époque, avec notamment au plus quatre partitions physiques sur le disque dur, lequel pouvait comporter (jusque dans les années 1990) au maximum 1024 cylindres, 256 têtes, 63 secteurs par piste, 2,2 téraoctets de capacité totale. Il a fallu longtemps jongler avec ces limites, jusqu’à ce que le constructeur Intel et à sa suite AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde, Microsoft, Phoenix Technologies, etc. créent l’UEFI Forum pour promouvoir l’Unified Extensible Firmware Interface (UEFI, « Interface micrologicielle extensible unifiée », standard publié en 2006, destinée à se substituer au vieux BIOS).

UEFI pour remplacer le BIOS

L’Unified Extensible Firmware Interface (UEFI, « Interface micro-logicielle extensible unifiée » donc) vient abolir les limitations énoncées ci-dessus pour le démarrage de l’ordinateur et l’amorçage du système d’exploitation. Elle est accompagnée du système de partitionnement GPT, pour GUID Partition Table (Globally Unique IDentifier Partition Table), capable de gérer un disque de capacité 9,4 ZB (9,4 × 10²¹ octets) ou 8 ZiB (9 444 732 965 739 290 427 392 octets).

Vient en sus un autre dispositif : Secure Boot, destiné à empêcher le démarrage sur cet ordinateur d’un système non signé par une autorité d’accréditation, en l’occurrence Microsoft. Là les choses commencent à paraître moins séduisantes. Cette élévation de Microsoft au rang d’autorité universelle chargée de délivrer ou de refuser le droit de fonctionnement à tout système d’exploitation est un privilège exorbitant. Inutile de dire que la communauté du logiciel libre n’a pas apprécié. Dans sa grande bonté et mansuétude, Microsoft a accepté de vendre des certificats aux éditeurs des principales distributions GNU/Linux pour la modique somme de US $99, somme symbolique, mais justement c’est un symbole lourd de conséquences, puisqu’il institue la suzeraineté de Microsoft sur ceux qui accepteront d’être ses vassaux. À ce jour Ubuntu, RedHat et Fedora ont accepté de passer sous les fourches caudines, mais pas Debian. Cela dit il est possible, dans le menu du BIOS, de désactiver l’option Secure Boot et d’activer Launch CSM (pour Compatibility Support Module) qui permet de s’affranchir de cette contrainte, mais en perdant une partie des avantages novateurs d’UEFI et de GPT.

Lorsque l’on achète un ordinateur équipé de Windows, le vendeur n’a en général pas envisagé que l’acheteur puisse souhaiter y installer un autre système d’exploitation, soit en remplacement de Windows, soit en partageant le disque de démarrage entre Windows et un autre système, par exemple GNU/Linux, selon le principe dit de double boot. Il appartient alors à l’heureux propriétaire de cet ordinateur de configurer son disque de façon à faire de la place pour le nouveau système qu’il souhaite y installer, à créer les partitions adéquates, et à le doter d’un logiciel d’amorçage qui permette de choisir au démarrage de l’ordinateur le système d’exploitation à lancer.

La suite de ce chapitre exposera la manière de configurer un disque de démarrage porteur de deux systèmes d’exploitation, en l’occurrence GNU/Linux et Windows, avec le logiciel d’amorçage GNU GRUB, sur une machine UEFI/GPT. Nous examinerons ici essentiellement ce qui est nouveau avec UEFI et GPT.

Le logiciel d’amorçage GNU GRUB

Installation de GRUB

GNU GRUB (GRand Unified Bootloader) est le logiciel d’amorçage de référence pour la plupart des distributions Linux et pour Oracle Solaris. Il peut lancer d’autres systèmes d’exploitation, tels que Windows ou les différentes variantes de BSD, et il peut charger des images de systèmes par le réseau. Il supporte divers formats d’exécutables, diverses géométries de disques, tous les systèmes de fichiers Unix, ainsi que les systèmes de fichiers Windows FAT et NTFS. Surtout, il permet d’avoir sur le même disque plusieurs systèmes d’exploitation et de choisir au démarrage celui que l’on veut utiliser (dual boot).

Depuis 2010 la version supportée par le projet GNU est GRUB 2, émanation du projet japonais PUPA (Preliminary Universal Programming Architecture) lancé en 1999 par Yoshinori K. Okuji dans le but de porter GRUB sur des architectures autres qu’Intel x86, de le rendre plus compact et modulaire, de le doter d’un langage de script, d’autoriser les caractères non-ASCII, et quelques autres améliorations.

En général l’installation de GRUB est réalisée par la procédure d’installation de toute distribution récente de GNU/Linux. Il est bien sûr possible de faire la même chose « à la main » avec les programmes utilitaires grub-install et grub-mkconfig, voire en écrivant son propre fichier /boot/grub/grub.cfg, mais nous n’entrerons pas ici dans ces détails [3].

Un bon schéma vaut mieux qu’un long discours, en voici un (ci-dessous) qui résume la configuration de GRUB sur un ordinateur avec un BIOS à l’ancienne, et en dessous ce qu’il en est avec UEFI et GPT.

Partition du disque

Les sections qui suivent décrivent les opérations de préparation d’un disque préalablement à l’installation d’un système GNU/Linux, soit seul, soit à côté d’un système Windows existant. De telles opérations dépendent étroitement des caractéristiques du matériel et de la distribution Linux utilisés, de ce fait les indications données ici ne peuvent avoir valeur de mode d’emploi à suivre à la lettre, mais plutôt de description des problèmes à résoudre et de pistes à suivre pour y parvenir.

Avec les BIOS à l’ancienne, la table des partitions stockée dans le MBR est limitée à quatre partitions. Pour contourner cette limite, il faut créer une partition dite « étendue » (partition 2 dans la figure ci-dessous), en quelque sorte une super-partition, à l’intérieur de laquelle il est possible de créer des partitions supplémentaires. Avec UEFI et GPT c’est plus compliqué, cette complexité est un obstacle sérieux à l’installation d’un système d’exploitation libre, même si les distributions Linux récentes facilitent le processus ; le résultat devra être conforme à la partie inférieure de la figure ci-dessous.

Installer Linux tout seul sur un disque

Plaçons-nous dans le cas de vouloir installer un système Linux sur un disque dur dont toutes les partitions auraient été effacées, au moyen par exemple du logiciel gparted. Les opérations à effectuer devront être les suivantes :

– Créer une clé USB bootable avec le système Linux désiré dont on aura téléchargé l’image ISO, par exemple Ubuntu pour fixer les idées. Cela se fait par exemple au moyen du logiciel UNetbootin, disponible sous Windows, MacOS et Linux.
– Démarrer l’ordinateur à partir de la clé USB.
– À partir du menu proposé, lancer Ubuntu en mode « essayer sans installer ».
– Lancer le logiciel de gestion de partition gparted.
– Au début du volume créer une partition étiquetée efi, 250 mégaoctets suffisent, type FAT32, avec le drapeau boot (attention, il ne doit y avoir qu’une seule partition efi sur un disque).
– Derrière cette partition efi créer une partition non formatée d’un mégaoctet avec le drapeau bios_grub.
– Puis créer les partitions Linux habituelles, par exemple pour une machine personnelle 30 gigaoctets pour la partition racine /, 4 Go pour la partition de swap, le reste à partager entre /home et /usr/local. Pour un serveur il faudra une partition à part suffisamment vaste pour /var, qui reçoit les journaux d’exploitation et les bases de données.

Il faudra sans doute aussi accéder au menu du BIOS au moyen d’une pression, pendant le démarrage, sur la touche F2, ou F9, ou F10, ou Escape, ou Delete, ou Suppr (cela dépend du système), et une fois ce menu affiché, désactiver l’option Secure Boot [4] si ce n’est fait. Si la distribution Linux utilisée refuse de s’installer en mode UEFI, il faudra, toujours dans le BIOS, activer l’option Launch CSM (CSM = Compatibility Support Module), qui revient au mode de l’ancien BIOS. Il est impossible d’être plus précis parce que cela dépend des versions de BIOS ou UEFI, de la distribution Linux utilisée, etc. Il est possible que certaines opérations énumérées ci-dessus soient effectuées par la procédure d’installation de Linux. Dans tous les cas de figure, pendant la procédure d’installation, afin de garder la maîtrise de l’organisation du disque, lorsque l’on arrivera à l’étape qui demande si l’on veut installer Linux en écrasant le contenu antérieur du disque, ou si l’on veut l’installer à côté de ce qui existe déjà, ou faire autre chose, il faut choisir faire autre chose, qui proposera le choix d’utilisation des partitions existantes, et éventuellement la création d’autres partitions.

On pourra consulter des éléments complémentaires d’analyse sur le site d’Éric Buist.

Installer Linux à côté d’un Windows existant

Si le disque de l’ordinateur contient un système Windows que l’on souhaite conserver,
il faut commencer par réduire la taille d’une partition Windows pour récupérer de l’espace pour Linux. Encore une fois gparted est le logiciel qui convient à cette tâche.

Il faudra peut-être aussi désactiver l’option Secure Boot et activer l’option Launch CSM (CSM = Compatibility Support Module, cf. ci-dessus). Encore une fois ces procédures ne sont pas normalisées et dépendent des versions des systèmes utilisés. Là aussi, pendant la procédure d’installation, lorsque l’on arrivera à l’étape qui demande si l’on veut installer Linux en écrasant le contenu antérieur du disque, ou si l’on veut l’installer à côté de ce qui existe déjà, ou faire autre chose, il faut choisir faire autre chose, qui proposera le choix d’utilisation des partitions existantes, et éventuellement la création d’autres partitions.

Voici un exemple de configuration de disque où cohabitent Linux et Windows, telle que restituée par le logiciel fdisk :

Disque /dev/sda : 232,9 GiB, 250 059 350 016 octets, 488 397 168 secteurs

Unités : sectors of 1 * 512 = 512 octets

Sector size (logical/physical) : 512 bytes / 512 bytes

I/O size (minimum/optimal) : 512 bytes / 512 bytes

Disklabel type : gpt

Disk identifier : 6A2E11D5-54AB-4C7D-A5E3-7101294F5A3B

Partition table entries are not in disk order.

La face obscure de l’architecture x86

Intel Management Engine

En octobre 2015 la chercheuse en sécurité informatique Joanna Rutkowska a publié un article retentissant intitulé Intel x86 considered harmful, qui étudie principalement les mécanismes peu connus du démarrage du microprocesseur, avant le lancement du système d’exploitation, et qui fait l’inventaire des failles de sécurité potentielles exploitables par un attaquant. Le résultat est très impressionnant.

Lors de la mise sous tension d’un ordinateur il faut que lui soit donnée une information d’amorçage : que faire pour commencer ? Plus précisément : quelle est l’adresse de la première instruction à exécuter ? On imagine bien que la modification de cette adresse par un attaquant pourrait compromettre irrémédiablement tout le fonctionnement ultérieur de quelque logiciel que ce soit, et notamment de tout système d’exploitation, aussi sûr soit-il.

Plus généralement, tout détournement malveillant d’une étape du processus d’amorçage peut corrompre toutes les opérations ultérieures, parce qu’à ce stade du démarrage aucun dispositif de protection matériel ou logiciel n’est activé, et qu’ainsi le BIOS (ou son successeur plus moderne) a accès sans restriction en mode privilégié à toute la mémoire et à tous les périphériques. Il est par exemple concevable qu’un BIOS corrompu par un attaquant lance une version corrompue du système d’exploitation. Cette question du démarrage est donc cruciale, d’autant plus qu’elle est généralement mal documentée et mal connue. C’est tout le mérite de Joanna Rutkowska d’avoir appliqué ses capacités d’investigation et de critique à ce processus, et d’avoir ainsi montré qu’en dépit d’une complexité considérable ajoutée au cours des dernières années pour en améliorer la sécurité, le système est encore vulnérable. D’où le titre de l’article.

Depuis 2014, comme nous l’avons déjà signalé ci-dessus, la plupart des ordinateurs sont livrés avec un programme de démarrage dit Unified Extensible Firmware Interface (UEFI), qui est essentiellement un BIOS écrit selon des principes plus modernes que ses prédécesseurs et doté de fonctions plus étendues, telles que la possibilité de disques de plus grande capacité avec un plus grand nombre de partitions. Un inconvénient majeur d’UEFI est la décision de Microsoft d’imposer aux vendeurs d’ordinateurs certifiés pour Windows 8 ou 10 l’obligation de livrer leur matériel configuré pour démarrer en mode dit Secure Boot contrôlé par une clé de chiffrement privée détenue par Microsoft et utilisée pour signer le noyau du système. Cette situation rend nettement plus difficile l’installation d’un système d’exploitation libre sur ces machines.

Système d’exploitation souterrain

Multiples sous-systèmes en micro-code

Pour corriger certaines failles de sécurité, les ingénieurs d’Intel ont multiplié les dispositifs : Trusted Platform Module (TPM), Trusted Execution Technology (TXT), exécution du code SMM (System Management Mode) sous contrôle d’un hyperviseur, Active Management Technology (AMT), Boot Guard, Secure Boot pour UEFI, et pour couronner l’édifice Intel Management Engine (ME)). Il s’agit en fait de systèmes implantés dans le micrologiciel du processeur, c’est-à-dire hors de portée de l’utilisateur même muni de tous les privilèges sur son système. L’article de notre auteure en fait une analyse approfondie.

Ce qui est à noter, c’est que des systèmes comme AMT et ME sont actifs en permanence, y compris lorsque l’ordinateur est arrêté (même lorsque l’ordinateur est hors tension mais branché au secteur, certains éléments restent sous tension, comme en témoigne par exemple le clignotement du LED du connecteur au réseau Ethernet RJ45) ! C’est dire à quel niveau de contrôle arrivent ces techniques, dont la puissance est telle qu’il est à souhaiter qu’elles ne puissent pas être détournées par des malfaisants.

Intel Management Engine (ME)

Nous ne traiterons pas ici de tous ces dispositifs, pour lesquels nous renvoyons à l’article, et nous n’évoquerons que ME (Intel Management Engine), parce que c’est le dernier en date et qu’il englobe en quelque sorte tous les autres. ME est un petit ordinateur incorporé à tous les processeurs Intel contemporains. Il est impossible de l’enlever ou de le désactiver, et d’ailleurs, à supposer que l’on trouve un moyen de l’inhiber, le processeur deviendrait pratiquement inutilisable parce que beaucoup de ses fonctions dépendent de ME.

Plus qu’un simple microcontrôleur, ME est une infrastructure d’accueil complète pour toutes sortes de sous-systèmes, et de fait AMT est désormais implanté sur ME, ainsi que Boot Guard, PTT (Platform Trust Technology, la version pour ME de TPM, et d’autres à venir. ME procure bien sûr un hyperviseur qui permet par exemple l’exécution de code SMM en bac à sable (pour une récapitulation de tous ces sigles on pourra se reporter au document Intel Hardware-based Security Technologies for Intelligent Retail Devices).

ME partout et pour tout ?

Joanna Rutkowska souligne les effets pervers de cette prise de contrôle par ME de tous les aspects du fonctionnement du système.

D’abord, imposer à tous les utilisateurs de processeurs Intel une technologie fermée et opaque en prétendant qu’elle offrirait un niveau de sécurité inégalable, sans discussion possible, est une attitude arrogante et peu convaincante sur le fond.

Ensuite, si cette idée s’impose, et il semble que l’on n’ait guère le choix (AMD développe des technologies comparables sous le nom Platform Security Processor, PSP), cela conduira à ce qu’elle appelle la « zombification » des systèmes d’exploitation tels que Windows, Linux, OS-X, etc., réduits au rôle d’interfaces avec l’utilisateur pour balader des fenêtres, réagir aux déplacements de souris et jouer de la musique, cependant que les véritables traitements de données seront effectués derrière les portes closes (par des clés de chiffrement détenues par Intel) de ME, sans que l’utilisateur sache quels sont les algorithmes utilisés, et avec quel niveau de sécurité.

Comment savoir, par exemple, si Intel n’a pas décidé de confier le séquestre de ses clés de chiffrement à un tiers de confiance, par exemple une agence de sécurité gouvernementale américaine ? ME pourra-t-il filtrer et analyser nos messages électroniques, nos communications par Skype, nos recherches sur le Web ? Le générateur de nombres pseudo-aléatoires de ME comporte-t-il des faiblesses, voulues ou non ? Répondre à de telles questions est déjà difficile aujourd’hui, mais Joanna Rutkowska attire notre attention sur le fait qu’avec ME la rétro-ingénierie nécessaire à leur compréhension et à leur analyse sera d’une difficulté accrue d’un ordre de grandeur.

Et si ME était corrompu ?

C’est la question qu’il faut toujours se poser à propos d’un système tout-puissant : tant que ses actions sont bénéfiques tout va bien [5], mais s’il est détourné vers des actions maléfiques, intentionnellement ou par suite d’une attaque réussie, alors l’empire du mal risque d’être absolu.

Or, pour qui voudrait entreprendre une action maléfique, ME est l’infrastructure idéale, nous dit Joanna Rutkowska : un rootkit implanté dans ME aurait le contrôle total des traitements effectués par le système et des données traitées (y compris les clés privées en transit par la mémoire), et il serait pratiquement indétectable. Que ce rootkit soit implanté par la mafia ou par la NSA ne change rien au problème.

Idées pour un système plus sûr

La démarche de Joanna Rutkowska lui permet d’élaborer les idées qui mènent à un système plus sûr, par exemple :

– utilisation intensive des techniques d’isolation des différents artefacts fonctionnels les uns par rapport aux autres : virtualisation et bac à sable (sandboxing) en particulier ;
– exécuter en mode non-privilégié tout ce qui peut l’être, et son article démontre que c’est possible pour presque tout ce qui a trait aux périphériques, ce qui annulerait les menaces de type Evil Maid et DMA par exemple.

Joanna Rutkowska ne s’est pas contentée de proférer des idées, qu’elle réunit sous le vocable compartimentation, elle les a mises en pratique en organisant le laboratoire The Invisible Things qui a créé le système d’exploitation Qubes OS fondé sur ces principes. On remarquera que cette idée de décomposer les systèmes en sous-systèmes le plus possible indépendants les uns des autres et dotés de privilèges réglés au minimum rejoint le courant des micro-noyaux, une technologie un peu oubliée mais dont les qualités de modularité, de flexibilité et d’aptitude au calcul réparti devraient permettre le retour au premier plan.

Elle constate avec dépit que de façon générale les industriels et les éditeurs de systèmes d’exploitation ne suivent pas ces principes et continuent à produire des systèmes monolithiques et donc vulnérables.

Il n’en reste pas moins que même en supposant toutes ces idées mises en œuvre, la question du démarrage reste entière, parce qu’elle est entre les mains des industriels qui conçoivent et fabriquent processeurs et cartes mères. La multiplication par Intel de technologies concurrentes ou complémentaires ne fait que compliquer la question : Trusted Platform Module (TPM)), Trusted Execution Technology (TXT), exécution du code SMM (System Management Mode) sous contrôle d’un hyperviseur, Boot Guard, Secure Boot pour UEFI, et pour couronner l’édifice Intel Management Engine (ME), qui est incorporé de façon irréversible à tous les processeurs Intel contemporains et qui est un véritable système d’exploitation implanté en micro-code et qui vit sous le système d’exploitation que l’utilisateur croit avoir choisi.

Avec Intel Management Engine le vrai système d’exploitation est dans les entrailles du processeur, et Windows, Linux ou OS-X ne sont plus que des systèmes de gestion de fenêtres, d’affichage de vidéo et de diffusion de musique. Ce qui est grave dans tout cela, c’est que non seulement l’utilisateur (et même le fabricant d’ordinateur) est privé de toute liberté de choix de son système, mais qu’en outre le système imposé n’offre pas et ne peut pas offrir les garanties de sécurité auxquelles il prétend.