COMPTOIR
  
register

Composé par ————— —— 11699 vues

Un outil de détection des binaires affectés par Spectre 1 chez RedHat

Les vulnérabilités Spectre et Meltdown, ça a foutu les pétoche à bien du monde, si bien qu'Intel s'est empressé de délivrer des mises à jours sur la plupart des OS et au niveau du microcode pour les CPU les plus récents, parfois même un peu trop vite.

 

Pour tout ceux non couverts par le correctif Spectre 1 (pour rappel, cette vulnérabilité permet d'utiliser une prédiction concernant les prochaines instructions assembleurs exécutées pour indûment aller charger des zones réservées et ainsi piquer des données normalement protégées), RedHat possède une solution. En effet, un analyseur de binaire vient d'être mis à disposition du grand public, et ce dernier permet tout simplement de déterminer si une application est oui ou non possiblement touchée par Spectre 1. Le mode d'emploi est assez simple : il suffit de donner le chemin vers le binaire et l'adresse correspondant à un point d'entré dans le programme et squalala, vous êtes partis. Autant dire qu'en cas de détection (le soft vous renvoie alors la séquence assembleur pouvant mener à un chargement spéculatif), mieux vaut prendre ses précautions et recompiler (ce qui nécessite donc un accès aux sources et un bon bout de temps devant soi..), la seule manière possible de supprimer cette faille-ci.

 

Si l'outil ne permet pas de patcher à la volée l'exécutable (c'eût été trop beau !) et se limite au exécutables x86_64 et Aarch64 n'utilisant pas de bibliothèques dynamiques, on salue un effort de transparence totale de la part d'une boite faisant de Linux son gagne-pain. A quand la version Windows ?

 

meltdown logo

Toujours pas fini avec cette fournée-là....

 

Tout est ici !
Un poil avant ?

En Allemagne, on interdit désormais les précommandes sans date de disponibilité précise...

Un peu plus tard ...

Et bim, 4,3 milliards d'euros d'amende pour Google !

Les 6 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Xorg, le Jeudi 19 Juillet 2018 à 21h38  
par Nicolas D. le Jeudi 19 Juillet 2018 à 21h23
Pour les deux remarques, l'outil s'adresse principalement aux noyaux en fait ; du coup on est sur quelque chose de statique et relativement complexe donc long à compiler
Ah ok, je n'avais pas vu que ça s'adressait principalement au noyau.
Ça peut prendre que quelques secondes selon la configuration du noyau et le(s) CPU(s) : Timed Linux Kernel Compilation.
Mais oui, un bon processeur fait toute la différence pour ce genre de tâche.
par Nicolas D., le Jeudi 19 Juillet 2018 à 21h23  
par Xorg le Jeudi 19 Juillet 2018 à 17h51
Le temps de compilation dépend de la quantité de code à compiler et de la machine. Pour compiler souvent du code, c'est rarement long.

Super. Sauf que ça fait belle lurette qu'on n'utilise plus de bibliothèques statiques. Dans la quasi-totalité des distributions GNU/Linux, tous les binaires utilisent des bibliothèques dynamiques.
C'est un peu dommage du coup...
Pour les deux remarques, l'outil s'adresse principalement aux noyaux en fait ; du coup on est sur quelque chose de statique et relativement complexe donc long à compiler
par Xorg, le Jeudi 19 Juillet 2018 à 17h51  
 
recompiler (ce qui nécessite donc un accès aux sources et un bon bout de temps devant soi..)

Le temps de compilation dépend de la quantité de code à compiler et de la machine. Pour compiler souvent du code, c'est rarement long.
 
il se limite au exécutables x86_64 et Aarch64 n'utilisant pas de bibliothèques dynamiques

Super. Sauf que ça fait belle lurette qu'on n'utilise plus de bibliothèques statiques. Dans la quasi-totalité des distributions GNU/Linux, tous les binaires utilisent des bibliothèques dynamiques.
C'est un peu dommage du coup...
par Zimmy, le Jeudi 19 Juillet 2018 à 14h08  
Ne pas oublier le coup de Squalala pour une détection plus rapide des binaires
par Un champion du monde en Île-de-France, le Jeudi 19 Juillet 2018 à 13h42  
Sympa comme outil mais je n'arrive pas à le compiler.
Peut-être que les bibliothèques Debian sont un peu trop vieilles et ne correspondent pas à celles qu'à utiliser le développeur.
par Un ragoteur tout mignon en Auvergne-Rhône-Alpes, le Jeudi 19 Juillet 2018 à 13h29  
Dans le genre bidon, il n'y a guère mieux...

Pour commencer, cet "utilitaire" n'est qu'un morceau de code pas fini (1) qui, de plus, ne peut détecter qu'une partie des "gadgets" (2), car il est incapable de suivre exhaustivement toutes les fils d'exécutions possibles (surtout dans un programme complexe tel un navigateur Internet).

Ensuite, rappelons que pour pouvoir implémenter une attaque Spectre, il faut non seulement un "gadget", mais aussi un moyen de faire exécuter celui-ci par le programme lui-même (par exemple, il faut un gadget dans le moteur Javascript d'un navigateur, et que le dit gadget puisse être appelé/déclenché via Javascript).

Enfin, il faut pouvoir monter le canal parallèle (side channel) permettant d'inférer les valeurs lues via le gadget (mais inaccessibles directement par le code attaquant), et cela requiert un chronométrage ultra-précis des opérations sur la mémoire; les navigateurs ont par exemple depuis été modifiés pour ne plus fournir de "timer" précis depuis Javascript.

Bref, c'est du vent !

(1) Bonjour la galère pour compiler ce truc qui ne contient pourtant qu'une paire de fichiers C ! Pas de script "configure" (en dépit de ce que dit le blog), nécessité de la présence de fichiers d'en-tête internes à binutils, nécessité d'éditer manuellement le Makefile...
(2) Séquences d'instructions dans le programme qui pourraient *éventuellement* être utilisées pour implémenter une attaque Spectre sur ce fichier binaire précis (rappelons qu'un même programme dans différentes versions ou simplement compilé avec différents compilateurs ou différentes options d'optimisation, aura un fichier binaire différent).