Les techniques de mitigation logicielles ciblant Spectre ne peuvent compenser les défauts de conception
Structurels des puces touchées, selon Google

Le , par Christian Olivier

200PARTAGES

12  0 
Un groupe de chercheurs travaillant pour Google affirme qu’il sera difficile d’éviter les bogues liés à Spectre à l’avenir, à moins que les CPU ne fassent l’objet d’une révision en profondeur. D’après eux, les techniques de mitigation basées sur les logiciels seules ne suffiront pas à empêcher l’exploitation de vulnérabilités matérielles de ce type, des solutions logicielles d’atténuation qu’ils considèrent, pour la plupart, comme incomplètes.


Il faut rappeler que c’est grâce à Google qu’on sait que les vulnérabilités critiques touchant les puces modernes, et probablement toute l’industrie des semi-conducteurs, affectent surtout les CPU x86 64 — bits d’Intel. Mais ces failles de sécurité touchent également les processeurs basés sur l’architecture ARM (Samsung, Qualcomm, MediaTek, Apple, Huawei…), l’architecture CPU mise au point par IBM et, dans une moindre mesure, les processeurs d’AMD.

Spectre correspond aux deux premières variantes — 1 (bounds check bypass) et 2 (branch target injection) — des vulnérabilités critiques découvertes par la firme de Mountain View et expose aux types d’attaques spécifiques qui y sont relatifs. Spectre brise la barrière entre les applications et permet à un attaquant d’obtenir, en toute discrétion, des informations sensibles sur des applications en cours d’exécution, même si elles sont protégées.

Les chercheurs de Google ont découvert que la temporisation du cache de données des processeurs modernes peut être utilisée de manière abusive pour récupérer illégalement les informations sur un ordinateur. Cette fonctionnalité est utilisée par la plupart des processeurs modernes pour optimiser les performances, mais elle peut également occasionner de graves problèmes de sécurité. Ils avaient réussi à démontrer que des attaquants peuvent tirer parti de cette fonctionnalité (connue aussi sous le nom d’exécution spéculative) pour exploiter des processus au niveau de l’espace utilisateur en contournant la MMU et lire le contenu de la mémoire du noyau d’un ordinateur qui en temps normal aurait dû leur être inaccessible.

Ce problème étant matériel, c’est-à-dire qu’il concerne la partie non reconfigurable des puces, il ne serait pas envisageable de recourir à un patch via microcode pour corriger toutes les variantes des différentes failles de sécurité révélées au cours des 14 derniers mois, notamment celles de Spectre. Pour remédier efficacement à ce problème, il faudrait soit recourir à une technique d’isolation de la table de correspondance, soit concevoir de nouveaux processeurs avec une architecture révisée en conséquence.

Dans un document distribué par ArXiv, les chercheurs de la filiale d’Alphabet assurent désormais que tous les processeurs qui prennent en charge l’exécution spéculative resteront toujours sensibles aux diverses attaques par canal latéral, malgré les mesures d’atténuation qui pourraient être découvertes à l’avenir. D’après eux, pour véritablement remédier à tous les bogues actuels et futurs liés à Spectre et à la menace qu’ils représentent, les concepteurs de CPU doivent s’atteler à proposer de nouvelles architectures pour leurs microprocesseurs.


Intel a dit qu’il inclura des correctifs matériels pour des bogues matériels spécifiques et connus dans ses futures puces. Le problème, selon les chercheurs de Google, est que les bogues liés à Spectre sont considérés comme une classe à part entière, et large de surcroit, de vulnérabilités liées à l’exécution spéculative qui favorisent les attaques par canal latéral.

Les chercheurs ont proposé plusieurs solutions possibles, notamment la désactivation totale de la fonctionnalité d’exécution spéculative, l’atténuation précise de la temporisation et « le branchless masking ». Ils ont fait remarquer que ces mesures d’atténuation ne sont pas sans poser de problèmes et qu’il est probable qu’il faille faire face à des pénalités au niveau des performances si elles venaient à être mises en œuvre.

Ils ont conclu en disant : : « Spectre porte peut-être trop bien son nom, car il semble destiné à nous hanter pendant longtemps », soulignant le fait que, depuis trop longtemps déjà, nous privilégions la performance et la complexité au détriment de la sécurité.

Source : Publication des chercheurs de Google (PDF)

Et vous ?

Qu’en pensez-vous ?

Voir aussi

AMD pourrait vendre plus de CPU serveur dédiés au cloud computing, après le scandale des vulnérabilités matérielles touchant surtout les CPU Intel
Sept nouvelles variantes de Meltdown et Spectre ont été découvertes par des chercheurs en sécurité, Intel ne se montre pas inquiet
PortSmash : une nouvelle faille critique qui affecte les CPU Intel exploitant l'Hyperthreading ou le SMT, des CPU AMD pourraient aussi être touchés
Microsoft publie des correctifs pour Foreshadow, une variante de Spectre, sur Windows 10 et Server 2016

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Ryu2000
Membre extrêmement actif https://www.developpez.com
Le 22/02/2019 à 14:31
Citation Envoyé par Christian Olivier Voir le message
Il faut rappeler que c’est grâce à Google qu’on sait que les vulnérabilités critiques touchant les puces modernes, et probablement toute l’industrie des semi-conducteurs, affectent surtout les CPU x86 64 — bits d’Intel. Mais ces failles de sécurité touchent également les processeurs basés sur l’architecture ARM (Samsung, Qualcomm, MediaTek, Apple, Huawei…), l’architecture CPU mise au point par IBM et, dans une moindre mesure, les processeurs d’AMD.
En ce moment Google recrute à fond chez Intel, Qualcomm, etc, pour créer ses propres processeurs.
On verra bien si Google fera mieux que les autres...
Avatar de Steinvikel
Membre éprouvé https://www.developpez.com
Le 23/02/2019 à 7:30
Qu'en pensez vous ?
"soulignant le fait que, depuis trop longtemps déjà, nous privilégions la performance et la complexité au détriment de la sécurité." --> je n'aurais pas mieux dit.

J'imagine qu'un tel problème ne serait jamais resté ignoré aussi longtemps sur du open-hardware. J'ai grande foi en nos futurs RISC-V question sécurité. =)
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 23/02/2019 à 8:35
J'imagine qu'un tel problème ne serait jamais resté ignoré aussi longtemps sur du open-hardware.
Le problème étant matériel, il faut :

  • remédier au problème de conception.
  • quid du matériel déjà fourni avec le défaut ? il faut le changer, ou accepter la mitigation, réduisant le problème mais ne le solutionnant pas à 100 %, générant un ralentissement global de fonctionnement.


Ca ne peut de toute façon pas se régler en 15 jours.

Les gens ayant acheté un CPU avec la faille peuvent toujours essayer de faire jouer le vice caché.
Avatar de cirle78
Membre régulier https://www.developpez.com
Le 23/02/2019 à 11:30
C'est vrai que depuis que spectre est sorti, je ne dors plus la nuit..... ;-)

Il y a des attaques revendiquées tous les jours par ce bug hard ;-)
Avatar de Steinvikel
Membre éprouvé https://www.developpez.com
Le 01/03/2019 à 9:14
Citation Envoyé par chrtophe Voir le message
Ca ne peut de toute façon pas se régler en 15 jours.
d'accord sur l'ensemble de ta réponse ...par "aussi longtemps" j'entends l'existence de la/les failles depuis plus de 20-30 ans. ^^'
Ce qui, il faut l'avouer, est extrêmement rare (encore plus) sur du libre, ou du 100% open-source.
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 01/03/2019 à 18:28
C'est pas parce que c'est opensource qu'il y a plus ou moins de failles :
Regardes cette actu (logiciel pas matériel) assez récente :
https://www.developpez.com/actu/2457...u-FOSDEM-2019/

En général, sur de l'opensource logiciel, les failles découvertes sont corrigés rapidement, mais encore faut-il qu'elles le soient.

Et pour le matériel, opensource ou non, si défaut de fabrication, il faut déjà revoir la conception.

C'est pas une soudure de résistance à refaire, c'est la conception à revoir, puis une fabrication à faire, pour ensuite procéder à une mise à disposition, sur quelque chose de très pointu.

Et faire un CPU en FPGA, je sais pas ce que ça peut valoir en terme de perf. Je pense que ça doit être bien en dessous de nos CPU actuels.
Avatar de Steinvikel
Membre éprouvé https://www.developpez.com
Le 01/03/2019 à 18:52
Ce que je voulais dire ce n'est pas que open-source = codage de qualité... mais que quand c'est open à 100%, et que c'est quelque chose qui est utilisé à outrance, il y a bien plus de personnes qui audit' la dite chose, bien plus de personnes qui tentent de malmener la dite chose, bien plus de personnes... que sur la solution équivalente propriétaire (partiellement ou pas)... et de facto, est, en comparaison, statistiquement plus fiable.

Un logiciel pris seul, la licence n'assure rien sur la qualité, elle te garantie de pouvoir contrôler la qualité. Si tu en prend plusieurs, par exemple, 7zip et WinRAR, en partant du principe que les 2 sont empiriquement autant utilisé (en comparaison d'illustres inconnus), on constate que WinRAR et 7zip ont tout 2 présenté des failles, buggs, etc. mais que statistiquement 7zip en présentait moins, ou moins graves, alors que les 2 ont une complexité comparable. C'est plutôt sur cet axe de logique que s'appuie mon propos précédent.

Donc oui, Libre != sans défaut, mais force est de constaté que ça y contribue fortement... un peu comme l'argent et le bonheur. ^^
Avatar de Ryu2000
Membre extrêmement actif https://www.developpez.com
Le 03/03/2019 à 10:07
Citation Envoyé par Steinvikel Voir le message
mais que quand c'est open à 100%, et que c'est quelque chose qui est utilisé à outrance
Citation Envoyé par Michael Guilloux Voir le message
La loi de Linus

En informatique, la loi de Linus, nommée en l'honneur de Linus Torvalds, et formulée par Eric Raymond, concerne le développement de logiciel. La loi indique qu’« avec suffisamment d'yeux, tous les bugs sont superficiels » ; ou plus formellement : « avec un groupe de bêta-testeurs et de co-développeurs suffisamment large, presque tous les problèmes seront rapidement analysés et le correctif sera évident pour l'un d'entre eux ». Présenter le code à une multitude de développeurs avec l'objectif d'avoir un consensus sur son acceptation est une forme simple de la revue de logiciel. La loi de Linus fait généralement partie de la philosophie de base des adeptes du mouvement open source et du logiciel libre.
Cela dit je pense qu'il y a plus de gens qui cherchent des failles dans le software que dans l'hardware.
Pour trouver Spectre ou Meltdown il faut déjà y aller... Même si l'intégralité de la conception du processeur était publique, il faudrait une grosse équipé de chercheur pour trouver les failles.
Il faut forcer un programme à accéder à des zones arbitraires de l'espace mémoire qui lui est allouée pour Spectre.
Meltdown permet à un processus non autorisé l'accès privilégié à la mémoire.

Citation Envoyé par chrtophe Voir le message
Les gens ayant acheté un CPU avec la faille peuvent toujours essayer de faire jouer le vice caché.
La quasi intégralité des processeurs Intel depuis 1995 sont potentiellement touché par Meltdown.
C'est impossible qu'Intel fasse un geste, Intel ne savait pas qu'il y avait une faille, ils l'ont pas fait exprès.
Et ça ne gène pas le fonctionnement du processeur.
Avatar de Steinvikel
Membre éprouvé https://www.developpez.com
Le 04/03/2019 à 12:55
Citation Envoyé par Ryu2000 Voir le message
Même si l'intégralité de la conception du processeur était publique, il faudrait une grosse équipé de chercheur pour trouver les failles.
Oui, mais sûrement moins grosse que dans un modèle où l'ingénierie que tu étudies est secrète, et que la communauté avec laquelle tu interagis pour renforcer ton travail ne peut s’établir dans la conception du sujet étudié (le processeur, l'architecture...).
Se serait comme tenter de relever des erreurs /incohérences de style de rédaction sur un document classé "secret", où les 3/4 du contenu est censuré, mais où il est pourtant possible dans déduire certaines infos censurés. --> le travail ne peut être aussi complet, aussi profond, et requiert de s'appuyer sur des aptitudes qui serait inutiles si tout le contenu était accessible, et donc l'emploi de plus de personne, de plus d'énergie ...pour un résultat bien moins probant.

PS: effectivement, c'est à la loi de Linus que je pense.
Avatar de Ryu2000
Membre extrêmement actif https://www.developpez.com
Le 04/03/2019 à 13:32
Citation Envoyé par Steinvikel Voir le message
Se serait comme tenter de relever des erreurs /incohérences de style de rédaction sur un document classé "secret"
Ouais ok c'est le principe de test "boite noire" / "boite blanche" et effectivement quand on a accès au code c'est plus facile de trouver certains problèmes.
Intel ne partage certainement pas tous les éléments de conception de ses processeurs avec les chercheurs et c'est donc plus compliqué de trouver les erreurs.

Cela dit je pense que si tu fais un processeur open source et qu'il contient des failles de sécurité, elles vont quand même être difficile à trouver, même si les chercheurs ont accès à tout.
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web