Meltdown et Spectre, faut-il vraiment s'affoler ?
07/01/2018
Noms judicieux, logos, timing (juste après les fêtes de fin d'année), site Internet dédié, matraquage médiatique, GIF montrant une démo de keylogger : le traitement marketing des dernières "failles" de sécurité informatiques est vraiment spectaculaire !
Ce qui l'est beaucoup moins c'est ce qui ressort de l'analyse du risque réel de ces menaces, avec les informations actuellement publiées.
Certes, le "risque" est confirmé par Intel " software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data" mais juste comme potentiel. A la base, le risque serait induit par l'optimisation de traitement d'un processeur qui profite des temps d'accès à la mémoire pour tenter sa chance en exécutant un code probable sans dispositif de protection d'accès à la mémoire pour cette exécution spéculative.
Cependant les deux articles de référence qui décrivent Meltdown et Spectre indiquent clairement que ces failles nécessitent l'exécution d'un programme sur la machine cible.
Et là, il n'y a rien de nouveau, on sait depuis toujours qu'on a presque perdu la partie contre un pirate dès lors qu'il est capable d'exécuter ses programmes sur la machine que l'on défend. La première préoccupation d'un administrateur système est la fiabilité des utilisateurs de ses machines.
C'est donc logique que les hébergeurs tels qu'OVH ou Online mettent autant d'énergie à appliquer des correctifs, tout en précisant qu'à ce jour il n'ont aucune preuve que ces attaques pourraient se réaliser en vrai " To date, OVH has not received any information demonstrating that the concerned vulnerabilities have been exploited outside of a research laboratory setting." Les hébergeurs savent que parmi leurs centaines de milliers de clients qui ont accès à leur machines, il y a certainement plus d'une crapule.
Dans le papier "universitaire" qui décrit Spectre, sur lequel pas moins de 10 auteurs se sont agglutinés, l'assemblage des techniques utilisées pour exploiter la faille hardware est impressionnante au point qu'on peut se demander si la somme des conditions favorables à l'exploit ne le rendrait finalement très peu probable. Il y a au moins un aspect décisif facile à comprendre qui n'est pas clair : le succès de la technique dépend-il de la présence de certaines instructions particulières dans un programme cible dont on veut dérober les informations détenues en mémoire ? On y donne un exemple de code hallucinant qui peut être exploité :
if (x < array1_size) y = array2[array1[x] * 256];
C'est bien de vérifier si l'index x est dans les limites du tableau array1 mais alors pourquoi ne pas aussi vérifier que l'index (array1[x]*256) est aussi dans les limites de array2 ? Si ce code est celui écrit par le pirate, il fait ce qu'il veut mais a priori il n'aura accès qu'au contexte de son propre programme comme l'article le précise "The completed attack allows the reading of memory from the victim process.". Si ce code doit figurer dans celui d'un autre programme exécuté sur la machine alors la probabilité qu'un tel code existe parait plus que très faible.
Il y a de nombreuses autres conditions ou réserves évoquées ou exprimées dans cet article telles que "Kernel mode testing has not been performed, but the combination of address truncation/hashing in the history matching and trainability via jumps to illegal destinations suggest that attacks against kernel mode may be possible."
Tout cela change complètement la réalité de la menace.
Malheureusement cela n'enlève rien aux conséquences qu'elle a déjà engendrées et qui sont irréversibles : un tsunami de mises à jour, une version plus qu'améliorée de l'obsolescence programmée :-(