Une faille de sécurité très importante a été découverte dans la gestion mémoire noyau des processeurs Intel, qui aura de graves conséquences sur l’ensemble des produits système de la Compagnie.

L’anomalie a d’abord été dévoilée par l’équipe sécurité « Project Zero » de Google, puis reprise par le média « The Register », qui lui a donné toute la publicité… qu’elle méritait.

Il s’agit d’une erreur de conception, qui remonte à dix ans, sur la manière dont est gérée la mémoire protégée des processeurs, celle qui est utilisée par le noyau des systèmes d’exploitation. Autrement dit « le saint du saint ».

Le problème est évidemment d’importance, car il va obliger les éditeurs de systèmes d’exploitation à revoir le code d’accès à cette mémoire « protégée », Windows, Linux et Unix, en fait toute la planète des OS, mais aussi d’autres fondeurs et développeurs de solutions.

Cela dit tout n’est pas clair dans cette affaire et nous distinguerons son côté technique de son aspect business.

Du point de vue technique, l’anomalie concerne la capacité que pourrait avoir un « attaquant » d’accéder aux données ultra-confidentielles de la mémoire protégée, celle où l’on trouvent les clés de protection utilisées par le système d’exploitation, les mots de passe et tout l’arsenal destiné à protéger l’OS des intrusions non autorisées.

Quant à l’aspect business, il soulève beaucoup de questions et concerne l’attitude des dirigeants d’Intel et de Brian Krzanich en particulier.

Processeur, micro-code et OS

Pour bien comprendre le danger de ce que l’on appelle désormais les failles Spectre et Meltdown, il faut se rappeler que l’exécution d’un programme compilé fait appel à trois niveaux de ressources : le matériel lui-même, le processeur qui a été imaginé logiquement pour exécuter un certain jeu d’instructions et bénéficier d’un contexte d’exécution bien précis, le micro-code qui est une sorte de paravent destiné à palier un problème ou un bug, constaté dans le processeur, vers lequel le code va être routé plutôt que de s’exécuter directement et le système d’exploitation, mais qui peut aussi concerner la simulation d’une fonction et le système d’exploitation.

Dans l’anomalie dont il est question ici, les chercheurs parlent d’erreur de design, de conception et accusent ouvertement Intel de s’être pris les pieds dans le tapis. Ce que le fondeur réfute, en estimant que d’autres fabricants ont exactement les mêmes problèmes que lui.

En fait, il y a deux failles : Meltdown qui ne concerne que les processeurs Intel et qu’un simple patch peut corriger et Spectre, qui concerne de très nombreux processeurs, d’Intel bien sûr, mais aussi d’ARM et AMD, voire probablement d’IBM et d’autres fondeurs de circuits.

L’ennui cette fois, c’est qu’il n’y a pas moyen de bloquer l’anomalie par un patch, car l’erreur est dans le matériel du processeur.

Meltdown et surtout Spectre sont des « exploits » fondés sur des failles conceptuelles trouvées dans le process d’anticipation d’exécution des circuits…et pas seulement ceux d’Intel. Meltdown a été découvert par trois équipes distinctes : des chercheurs autrichiens de l’Université Graz, la firme allemande Cerberus Security et le groupe Project Zero de Google. Spectre a été mis en évidence par ce même project Zero de Google, mais aussi par le chercheur Paul Kocher.
Un problème conceptuel

Ce qui est curieux dans l’affaire « Spectre/Meltdown », c’est qu’elle soit fondée sur un défaut de conception, que les fondeurs connaissent depuis longtemps, chez Intel en particulier.

Il s’agit d’une fonctionnalité dite d’exécution anticipée du code, le processeur pouvant intégrer à sa pile d’exécution un flot d’instructions, en anticipant sur celles qui succèderont à l’instruction courante. Selon le contexte, la nature de l’instruction à exécuter et différent critères, le processeur prépare la « machine » à la suite, en faisant en sorte qu’il n’y ait pas de nouveaux chargements à exécuter et que tout soit prêt. Histoire de gagner des cycles…

Cette disposition est presqu’aussi vieille que les processeurs. Mais elle est aussi mise en œuvre très différemment selon les circuits, ce qui explique qu’aujourd’hui il y ait polémique et que certains fondeurs ne se sentent pas concernés par le vent de folie qui gagne la planète, AMD surtout (qui se frotte les mains…).

Cette disposition d’exécution anticipée du code, dite aussi d’« exécution spéculative », dans la mesure où le processeur spécule sur les instructions à venir, met en scène différents composants du circuit, les gestionnaires de caches, instructions et data, ainsi qu’un bloc essentiel, le gestionnaire mémoire, qui prend en charge les accès à la mémoire privilégiée, celle à laquelle seule le noyau a le droit d’intrusion, puisqu’il est le seul à disposer des privilèges nécessaires.

C’est cette organisation, devenue une faiblesse, qui a été plus ou moins utilisée par les criminels pour lancer leurs attaques. Meltdown est l’une de ces attaques, heureusement facile à enrayer, de même que Spectre, très récente, qui elle nécessite une véritable stratégie de protection, qu’un simple patch ne permet donc pas d’endiguer. Une stratégie de correction et de prévention qui ne sera pas sans conséquence sur les performances des machines, aussi bien serveurs que clientes (tout le monde est dans la même galère).

Les corrections à envisager

Le moins que l’on puisse dire est que la planète n’est pas restée sans réagir, aussi bien les fondeurs que les éditeurs d’OS et les communautés Open Source, Linus Torvalds en tête, qui regrette quand même le comportement d’Intel, dont la communication laisse pour le moins à désirer :

« Je pense que quelqu’un chez Intel devrait regarder leurs CPU et admettre qu’ils ont des problèmes au lieu d’écrire des communiqués en langue de bois, qui affirment que tout fonctionne comme prévu ». Et de poursuivre avec sa légèreté habituelle : « Est-ce qu’Intel est en train de nous dire qu’ils s’engagent à nous vendre de la merde pour toujours et qu’ils ne répareront jamais rien ? ».

Des propos certes violents, mais qui au fond, résument bien la situation d’Intel, engagé dans une opération de séduction, qui fait tout pour minimiser l’évènement, quitte à le nier, histoire de protéger le cours de l’action.

Pour ce qui est des fondeurs, il faudra qu’ils revoient l’architecture matérielle de leurs circuits, ce qui va évidemment prendre du temps, induira d’attendre de nouvelles versions et nécessitera de patienter avec du micro-code correctif. Intel est dans ce cas.

Les éditeurs d’OS vont devoir, quant à eux, procéder à des changements profonds dans le code de leur noyau et séparer par une frontière plus imperméable les accès aux données clients, des données du noyau, celles qui nécessitent une protection absolue.

Il y aura là deux possibilités, soit le processeur mettait déjà en œuvre des tables distinctes client et « kernel », une fonction KPTI (kernel Page Table Isolation), comme le fait AMD et la vulnérabilité disparaîtra en partie, soit cette disposition est introduite et il faudra alors que l’éditeur revoie sa manière d’accéder à la mémoire protégée, en fonction de cette disponibilité.

Ce qui d’ailleurs entraînera des pertes de performances que l’on peut estimer entre 3 et 30 % pour l’OS et les applications basées sur Intel.

Le spécialiste PostGreSQL a par exemple établi que les applications qui accèdent à sa base de données seront ralenties entre 17 et 23 %, du fait de la séparation de ces fameuses tables.

Les patchs à venir

Microsoft a déjà émis un patch en dehors de toute procédure, pour Windows 10. Et dès le 9 janvier, lors du traditionnel Patch Tuesday, émettra les patchs pour les autres versions de Windows.

Du côté de Linux, les responsables du noyau ont déjà publié les patchs pour implémenter la séparation KPTI et déplacer le noyau dans un espace mémoire adapté et séparé.

Chez Apple, une première salve de correctifs a été apportée avec macOS High Sierra 10.13.2, il y a quelques semaines, qui sera complémentée par d’autres correctifs avec la 10.13.3 à venir.

Quant à Google, la mise à jour sécurité de janvier a été publiée, pour ses propres terminaux Pixel/Nexus, les autres usagers d’Android devant attendre le bon vouloir (et la bonne volonté) de leur intégrateur, pour se protéger efficacement, contre ce qui s’annonce quand même comme l’un des plus grands dangers encourus en matière de sécurité détectés ces dernières années.

Que penser du rôle de Brian Krzanich

On pourrait se contenter de ce constat et se dire qu’après la pluie, le soleil finira toujours par réapparaître.

Saut qu’il y a plus gênant.

Car on sait aujourd’hui que Brian Krzanich, CEO d’Intel depuis 2013, a vendu fin novembre pour 11 millions $ d’actions Intel, à un taux préférentiel, comme le prévoient la loi américaine et les statuts d’Intel, ce qui l’a ramené au taux minimum d’actionnariat qu’impose la même loi, pour qu’il puisse continuer à prétendre au titre de PDG de la compagnie.

Cette vente d’actions providentielle s’est produite au moment même où Intel était averti de l’existence des deux fameuses failles et avant, bien entendu, que le cours Intel ne soit chahuté en Bourse (–3 % en une seule journée).

Evidemment pour Intel, tout cela n’est que calomnie et rien ne relie la vente des actions du CEO à Spectre. Ce n’est qu’une coïncidence…

De nombreux observateurs ne sont pas de cet avis et l’enquête à venir, pourrait confirmer que le délit d’initié reste un sport très pratiqué par certains managers de très haut niveau.

Rappelez-vous l’affaire Equifax en septembre. Là aussi trois dirigeants « insoupçonnables » avaient vendu leurs actions en catimini, alors qu’une faille géante de leur système, mettait en péril les actifs de plus de 140 millions d’américains…

Equifax, maintenant Intel, décidément 2018 commence pour certains hauts managers…