Meltdown et Spectre, faut-il vraiment s’affoler ?

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 🙁

Meltdown and Spectre: the juiciest bug of 2018?

2018 starts wonderfully: a new kind of vulnerability has been disclosed, an hardware bug!

Documentation about this is available from sources with considerable authority, from university researcher or google official blog.

However, a closer analysis of the threats raises doubts about their seriousness. The risk to be affected by them seems rather low.

“...Meltdown allows an adversary who can run code on the vulnerable processor…” [https://meltdownattack.com/meltdown.pdf]. Thus for dedicated server, the vulnerability implies a logged attacker. Of course for VM or VPS, you don’t control who runs code on the physical host you share. But servers administrator core preoccupation is to keep attacker from logging on their systems.

As for “Spectre” [https://spectreattack.com/spectre.pdf], the so called proof of vulnerability – among other prerequisites unlikely to happen – relies on the “victim” code to have an instruction such as “if (x < array1_size) y = array2[array1[x] * 256];“! Who would write such a code and what for?

These two quoted papers remind of academic context where such unpractical conditions hidden behind well handled complexity are often observed. The underlying techniques are too complex to be easily understood but the presentation is convincing.

Even google (https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html) admits that “To take advantage of this vulnerability, an attacker first must be able to run malicious code on the targeted system.

Anyway, even if the risk is much lower that it is presented, the inevitable result will be a massive update frenzy: an ideal opportunity to deploy other vulnerabilities, spywares or backdoors and to motive hardware replacement…

First, the software fix will decrease performance: a motivation to invest in faster – and more expensive – systems. Eventually the hardware fix will require new computers. Thus it is not surprising that all CPU vendors happily admit that their products are affected.

Whatever dangerous Meltdown and Spectre may be, they are certainly a huge opportunity of profit.

Well done.