OpenBSD : Theo de Raadt convaincu que l'HyperThreading d'Intel est un danger

Décidément, 2018 est un vrai casse-tête pour le monde des processeurs en général, et pour Intel en particulier depuis la révélation au public des failles Meltdown et Spectre. Brian Krzanich doit certainement tout même être un peu soulagé de pouvoir désormais assister de loin au spectacle sans plus avoir à se salir les mains, car rares sont les mois qui se passent sans une nouvelle trouvaille. Certes, l'exploitabilité des failles est rarement des plus évidentes, mais leur existence seule suffit pour inquiéter, tout particulièrement ces milieux où la sécurité est une bataille de tous les instants. Le dernier trou en date est le L1 Terminal Fault, auquel OpenBSD avait déjà réagi un mois avant la publication des 3 vulnérabilités en supprimant l'HyperThreading de la version 6.4 d'OpenBSD !

 L'HyperThreading, un long chemin depuis 2004 !

Il y a quelques jours, le fondateur d'OpenBSD, Theo de Raadt, est d'ailleurs revenu un peu sur le sujet. Il explique notamment que les mitigations via l'installation de patchs et de microcodes ne sont pas suffisantes pour garder les pirates à la porte, et réaffirme que les failles L1TF et TLBLeed obligent désormais également à la désactivation complète de l'HyperThreading. De plus,  malgré la difficulté d’implémentation de ces attaques par canaux auxiliaires, Theo est convaincu que des hackers découvriront tôt ou tard des méthodes d'exploitations fiables pour faire fuiter le kernel ou la mémoire commune lors de l'utilisation de virtualisation dans des conditions d'utilisations courantes !

En ce sens, le fondateur d'OpenBSD croit fermement que l'HyperThreading exacerbera au fil du temps la majorité des failles liées à l’exécution spéculative, d'où la nécessité de le désactiver sans détour. Simultanément, de Raadt critique aussi Intel pour son manque de transparence et d'assistance en matière de documentation et de recherche et développement pour les moyens et méthodes de mitigations. Histoire d'enfoncer le clou, Theo acheva son paragraphe par un "j'irai dépenser mon argent chez un vendeur plus fiable à l'avenir" assez peu équivoque...

Du haut de son château, Intel estime toutefois que la désactivation de l'HyperThreading n'est pas une nécessité, au moins tant que les autres techniques de mitigation ont bien été utilisées, à quelques exceptions près, par exemple lorsque les administrateurs et fournisseurs cloud ne peuvent garantir que leur matériel a bien été mis à jour. Hors virtualisation, les risques seraient par contre moindres dès lors que les mises à jour ont été correctement installées, toujours selon Intel. À condition bien sûr de pouvoir le faire, ce qui n'est forcement toujours le cas en fonction de l'assembleur ou constructeur, et aussi de l'âge du matériel.

En fin de compte, même s'il est encore difficile de jauger avec exactitude le niveau de danger que représentent ces failles, il est assez évident qu'il est de la responsabilité d'Intel - et des autres fabricants de microprocesseurs - d'assurer la sécurité complète de leurs produits auprès de la clientèle. (Source : Tom's)

"J'suis pas content, ok !?".