Greg Kroah-Hartman : à l’heure de Spectre et Zombieload « vous devez choisir entre la sécurité et les performances »

Anthony Nelzin-Santos |

RIDL, Fallout, Zombieload, MDS… Pas un mois ne passe sans qu’apparaisse une nouvelle version de Spectre, cette faille qui exploite les mécanismes d’exécution spéculative des processeurs, et permet à une application malveillante d’extraire les données d’une autre application. « Nous allons vivre avec ces problèmes pendant longtemps », explique Greg Kroah-Hartman, l’un des principaux développeurs du noyau Linux, au cours d’une conférence donnée lors de l’Open Source Summit Europe, le grand raout de la fondation Linux.

Greg Kroah-Hartman lors de l’Open Source Summit Europe 2019. Image MacGeneration.

RIDL et Fallout touchent la dernière génération de processeurs Intel, qui comprennent pourtant des garde-fous contre les failles touchant les mécanismes d’exécution spéculative. Contrairement aux attaques comme Spectre ou Foreshadow, qui concernent les caches des processeurs, RIDL et Fallout s’intéressent aux mémoires tampons internes aux processeurs. Autrement dit : un problème jugé « exceptionnel » l’an passé s’avère systémique.

« Les problèmes des processeurs modernes sont bien plus profonds que nous le pensions », explique l’équipe de recherche qui a découvert les failles exploitées par RIDL et Fallout. « Les processeurs sont devenus si complexes que les fabricants sont incapables de contrôler leur sécurité », poursuit-elle, « nous n’avons aucune idée du nombre de failles matérielles ”zero-day” encore exploitables. Si nous ne pouvons pas faire confiance à notre matériel, alors les fondations de nos solutions de sécurité s’effritent. » Un sentiment partagé par Greg Kroah-Hartman, qui évolue de l’autre côté du miroir, puisqu’il coordonne la défense du noyau Linux contre ces attaques.

Toutes ces failles exploitent les mécanismes d’exécution spéculative : pour accélérer les opérations, les processeurs essayent d’anticiper la prochaine action, d’une manière qui peut être abusée par des applications malveillantes. Même si certains processeurs AMD et ARM sont vulnérables à certaines attaques, les processeurs Intel sont plus durement touchés. Et même si ces failles peuvent être exploitées sur tous les appareils dotés d’un processeur moderne, elles concernent plus particulièrement les serveurs, puisqu’elles peuvent franchir les limites des machines virtuelles et des conteneurs.

Or Intel est un acteur central dans le domaine du cloud computing, qui repose très largement sur le noyau Linux (dont Intel est, par une ironie cruelle, le premier contributeur). Les dernières failles exploitent des problèmes de conception du mécanisme d’hyperthreading d’Intel, qui permet d’exécuter deux opérations — deux threads — simultanées sur un seul cœur. Comme les deux threads partagent la même mémoire cache, une attaque bien conçue peut récupérer les données du thread voisin. Les barrières des applications, des machines virtuelles, et même de la Secure Enclave des processeurs Intel peuvent ainsi être franchies.

La communauté formée autour d’OpenBSD, un système UNIX particulièrement attaché à la sécurité, a réagi en désactivant complètement l’hyperthreading. « Je tiens à les féliciter pour leur réponse rapide », concède Greg Kroah-Hartman, « mais ils ont fait le choix de la sécurité contre les performances ». « Même si ces failles exploitent des problèmes matériels, nous devons essayer de les régler avec des mises à jour du noyau et du BIOS » : désactiver l’hyperthreading, ou mettre à jour le BIOS sans mettre à jour le système, « ne suffit pas ».

Problème : la solution pour boucher les failles RIDL et Fallout, qui consiste à vider la mémoire tampon à chaque fois que l’on change de contexte, prend du temps. Chaque patch, à sa manière, grève un peu plus les performances. « J’ai constaté jusqu’à 20 % de baisses des performances en compilant le noyau de Linux », explique Greg Kroah-Hartman. De fait, les opérateurs de services dans le nuage sont obligés de choisir entre les performances et la sécurité : certains appliquent les patches et désactivent l’hyperthreading, d’autres reviennent sur les mesures de « mitigation ».

Le développeur conclut sa « triste présentation » par une déclaration-choc : « si vous utilisez un système stable, vous n’utilisez pas un système sécurisé ». Les distributions GNU/Linux suivent, peu à peu, l’exemple d’OpenBSD. Microsoft recommande, dans certains cas, de désactiver l’hyperthreading dans les environnements serveur qui utilisent des machines virtuelles. Et Apple ? Au-delà des mises à jour explicitement dédiées à Spectre et Meltdown, ou plus récemment à Zombieload, la firme de Cupertino n’a pas dévoilé ses intentions pour prévenir l’exploitation des failles de l’hyperthreading à long terme.

avatar SquallX | 

Très intéressant comme billet. On comprend mieux pourquoi les fondeurs multiplient les cœurs. 8 cœurs sans HT passeront mieux que 4 sans quand il n’y aura d’autre solution que désactiver les cœurs virtuels.

avatar totoguile | 

Je pense que cela va être une tendance lourde effectivement : multiplier les coeurs et ne pas implémenter l'HT. Apple a une opportunité en développant ses propres CPU pour ses ordinateurs, et non plus seulement ses iPhone/iPad...

avatar Dimemas | 

Il n’y a pas que ça...
Amd est clairement moins touché qu’intel et la prochaine génération sera touchée elle aussi alors qu’amd Ne l’est plus vraiment !

Il faut aussi prendre en considération que intel reste bloquée sur le 14nm et ne veut pas avouer qu’ils ont abandonné le 10nm parce qu’ils n’y arrivent pas !
Pour être au niveau d’amd, ils doivent augmenter leurs nombre de cœur !

Quand on voit qu’un 3600 est à la hauteur d’un 9700k (6 vs 8 cœurs quand même !!)

Et attendez ! Zen 3 apportera 4 cœurs virtuels par cœur !
Intel est vraiment dans la merde !

Je ne comprends pas pourquoi Apple persiste encore avec intel qui est à la ramasse et totalement insécurisé !

avatar krully37 | 

@Dimemas

A part quelques cas très particuliers il faut être un fanboy (et être fanboy d’une marque qui a abusé de sa position dominante pendant 10 ans et a refusé d’innover il faut le faire) pour monter un PC sous chipset Intel c’est clair. Quand on voit qu’AMD fait mieux pour moins cher sur tous les fronts et que Zen 3 va encore enfoncer le clou... Intel l’aura bien mérité, entre les grilles tarifaires abusives, les nouveaux chipsets tous les 6 mois et leur incapacité à produire autre chose que des radiateurs ces dernières années.

Maintenant il faut espérer qu’Apple se penche sur le cas Ryzen, leur partenariat sur les GPU laisse un espoir.

avatar marc_os | 

@krully37

J’ai cessé de lire ton commentaire interminable dès que j’ai lu le mot fanboy qui discrédite le tout. 😛

avatar Dimemas | 

bah tu devrais pousser ta lecture parce qu'il est dans le vrai...

avatar Dimemas | 

@ krully :
sache tout de même que j'ai fait un hackintosh sur un ryzen 3600 et qu'il marche du feu de dieu !

avatar fousfous | 

C'est pour ça qu'on a pas de cœurs virtuels sur les processeurs Apple?
Sur les Mac beaucoup de processeurs ont de l'hypertherding, une désactivation en vue?

avatar malcolmZ07 | 

@fousfous

Je pense qu'ils exécutent tout simplement moins de tâche simultanément que les intel

avatar Dev | 

Très intéressant manque plus que Apple montre qu’ils penche sur le sujet eu aussi car l’ère des Mac sans virus est terminée depuis bien longtemps ...

avatar mmmathieu | 

@Dev

Nuance, sans malware...
Les virus (même chez Windows et Linux) ne sont qu’un vieux souvenir ou presque...

avatar Bigdidou | 

Je ne sais pas quel genre de cerveau peut comprendre totalement et surtout manipuler ces concepts.
Je suis totalement admiratif et tout aussi paumé quand on me parle de ses choses à la fois concrète et qui me paraissent totalement abstraites, quasi ésotériques.

Bon courage à ceux qui vo t nous concevoir les générations suivantes d'ordinateurs...

Si je comprends bien, il va falloir changer de point de vue : comme en sécurité routière, la sécurité informatique totale est une chimère, et il faut vivre avec un niveau de risque qu'il s'agit juste de rendre le plus acceptable possible.

Après, le ploitation de ces failles, c'est quand même réserve à une élite, non ?

avatar sebasto72 | 

@Bigdidou

« Après, le ploitation de ces failles, c'est quand même réserve à une élite, non ? »

Un élite large alors :)
Une fois une faille découverte (et là, il faut des cerveaux oui), on retrouve des kits prêts à l’emploi pour être utilisés à grande échelle...

avatar smog | 

@Bigidou : je pensais la même chose.
J'ajoute qu'à force, le seul moyen d'être "en sécurité", c'est de ne pas être connecté au réseau ? est-ce le truc d'avenir, avoir deux machines systématiquement, dont une non-raccordée ?

avatar mouahahaha | 

"est-ce le truc d'avenir, avoir deux machines systématiquement, dont une non-raccordée ?"

Absolument pas, même comme ça ya moyens d'extraire des données sur une machine qui n'a jamais été connectée à internet. C'est pas très rapide mais c'est quand même possible...

avatar Achylle_ | 

Très intéressant oui.
UN peu flippant aussi, car cela touche au hardware et c'est donc très embettant.
Car si on n'est plus a l'abri dans une VM ou un docker, c'est un peu flippant !

Apple a une carte à jouer, mais vu qu'ils ne communiquent pas, c'est compliqué de se prononcer.
Je crois très fort dans l'ipad pro et dans ce qu'il deviendra.
ARM étant touché par ces failles, est ce que quelqu'un sait si cela touche les SoC A12/A13 et consort ?

avatar kafy28 | 

Je pense que le vrai souci est moins pour les utilisateurs lambda que nous sommes que pour les états et entreprises.
Le piratage d'un PC pour escroquer quelques centaines d'euro peut vite se résoudre par une bonne sauvegarde.
Alors que le piratage de serveurs d'état, de service d'état (ex : hôpitaux) ou d'entreprises devient un vrai risque pour nous tous.
Imaginer que les station de filtrage d'eau, de distribution d'électricité , ... soient piratées ... cela peut devenir une très grave crise humanitaire en quelques jours.
Des états, des groupes terroristes et des "mafia" sont les premiers clients des nombreux spécialistes prêt à vendre leur savoir.

avatar Nesus | 

@kafy28

C’est ça. Ça reste des failles « compliquées » à mettre en place. Alors un tel hack sur un serveur, c’est extrêmement intéressant, sur un ordi lambda... faut vraiment avoir une cible et une raison précise. Toutefois, ça reste très problématique, surtout parce qu’il n’y a as de vraies solutions.

avatar mouahahaha | 

"faut vraiment avoir une cible et une raison précise."

Comme un journaliste, un avocat ou un opposant politique ? :)

avatar Mike Mac | 

Ah, je vois bien la panne de courant à domicile et les compteurs Linky afficher un message de réseau piraté alors que ceux avec le bon vieux compteur traditionnel utilisant d'autres canaux de distribution à l'ancienne recevraient toujours la fée électricité....

avatar SyMich | 

Compteur pinky ou traditionnel, si les centrales nucléaires partent en cacahuète parce que leur contrôle/commande est piraté, on sera dans la même galère...

avatar TheUMan | 

C'est Linky pas Pinky ;-)

avatar marc_os | 

« noyau Linux (dont Intel est, par une ironie cruelle, le premier contributeur) »

Euh.... en quoi est-ce ironique ?
Et en quoi cette ironie est-elle cruelle ?
Intel fabrique des processeurs, Linux est un OS, un composant indispensable pour les exploiter.
Où est l’ironie ??

avatar Anthony Nelzin-Santos | 
@marc_os : le principal mainteneur du noyau Linux qui se plaint d’Intel, principal contributeur du noyau qu’il maintient ?
avatar mouahahaha | 

Être le principal contributeur ça veut pas dire que tu t'occupes de tout dessus mais que tu commits le plus ou que t'ajoutes pas mal de ligne au noyau. Comme microsoft la fait une période pour ses propres techno.

S'il faut 100 commits à intel pour ajouter le support du nouveau cpu quand amd fait la même chose en 20... Ca fausse la donne.

Ou que tu commits un truc et que derrière t'as besoin de 3 autres pour rectifier des conneries que t'as fait dans ton code, ça augmente articifiellement ta place.

Cest pareil avec le nombre de ligne de code en plus, et comme on la déjà vu. Certains ont reprit des portions de code et on produit un résultat largement superieur en beaucoup - de ligne qu'à la base.

Commits beaucoup, en nombre de ligne de code ou en patch soumit, n'induit pas que le travail fait est qualitatif mais juste quantitatif. Si le plus gros fait de la merde, c'est pas une mauvaise chose de lui rappeler et ya aucun mal à ça. :)

Pages

CONNEXION UTILISATEUR