Quelqu'un a-t-il vérifié de manière indépendante le script Shell de Speed 47 (spectre-meltdown-checker.sh) qui vérifie les correctifs Meltdown et Specter?
Il y a ce code qui vérifie si votre noyau a été corrigé pour Spectre et Meltdown. C'est à: https://github.com/speed47/spectre-meltdown-checker
D'autres commentateurs ont parlé des limites de sa méthode, mais je n'ai trouvé personne qui puisse dire s'il est sûr de fonctionner en tant que root.
Quelqu'un peut-il intervenir sur l'aspect sécurité de ce script?
Effectue-t-il autre chose que la vérification de ces vulnérabilités, telle que la modification de la configuration du système, ou apporte-t-il des modifications qui pourraient survivre au-delà du redémarrage?
Je vous remercie
Le script vérifie actuellement les mesures d'atténuation dans le noyau pour les trois vulnérabilités. A ce jour, les systèmes LTS et Ubuntu 17.10 disposent des mesures d'atténuation possibles pour la vulnérabilité Meltdown.
Il existe un programme C pour déterminer l’une des vulnérabilités de Spectre. Vous pouvez vérifier si votre processeur est vulnérable avec:
wget https://Gist.githubusercontent.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6/raw/41bf9bd0e7577fe3d7b822bbae1fec2e818dcdd6/spectre.c
gcc spectre.c -o spectre -std=c99 -w -O0
./spectre
Si vous pouvez voir des lignes avec:
Reading at malicious_x = 0xffffffffffdfebb8... Success: 0x54=’T’ score=7
Votre processeur est alors vulnérable à la prédiction de branche Spectre.
J'ai personnellement testé Intel Atom 1ère génération, Core 2 Duo E8400, Core 2 Duo 4300 pour ne pas être vulnérable et Core i5 3230M, AMD Turion TL-56 pour être vulnérable en fonction de l'exécution de ce programme.
Tout d’abord, quelques faits tirés de la page github du projet. Au moment de la rédaction de cet article, il compte 48 contributeurs et 355 fourchettes. Un contributeur peut être quelqu'un qui n'a vu qu'une partie du script et modifié un domaine qui l'intéresse, mais il est plus probable qu'autrement il ait lu tout le texte pour apporter sa contribution au code. C'est donc déjà un niveau important de vérification. Il y a aussi 355 fourchettes mais, voyant que tout ce que vous avez à faire, c'est d'appuyer sur un bouton pour en créer un, faites-en ce que vous voulez.
Ensuite, il ne faut jamais compter sur Virus Total pour vérifier les scripts ou le code source. Peut-être qu'un jour AI sera écrit, capable de lire les scripts/le code source afin de rechercher des contenus malveillants, mais pour le moment, personne ne s'est vraiment mis en mesure de les vérifier automatiquement. Les antivirus recherchent des signatures binaires et peuvent parfois utiliser une approche heuristique pour analyser des fichiers binaires. Si vous attribuez un code source ou un script à un antivirus, celui-ci sera interprété comme un fichier texte et vous indiquera qu'il est propre (ce qui crée un faux sentiment de sécurité).
Enfin, je viens de terminer la lecture de toutes les 4500 lignes et je n’ai rien trouvé qui me préoccupe.
Divulgation complète, je me considère seulement comme un scénariste de bash intermédiaire et c’est un script assez avancé que je vais probablement cannibaliser pour obtenir des conseils et astuces pour les années à venir. Bien que je sois capable de suivre le rythme, il est possible que j'ai raté quelque chose car il se passait beaucoup de choses.
La plupart de ses opérations impliquent de faire des lectures dans le noyau, cpuid, la configuration du noyau, le fs (les parties liées au correctif et aux informations du noyau nécessaires à son travail) et le msr de cpu. Il fait quelques écritures, extractions, dumps et décompilations qui se produisent dans le dossier temporaire et sont supprimés lors du nettoyage de sortie. Le seul moment où il utilise Internet est d’utiliser wget pour télécharger une base de données MCExtractor à partir de sa page github. Il n'essaie en aucun cas de téléphoner à la maison.
Lors de la lecture, je n’ai trouvé que deux choses importantes à noter: la première est qu’il écrit deux fois dans les registres spécifiques au modèle (msr) de la CPU (c’est là que sont stockés les paramètres de la CPU). C’était alarmant au début, mais j’ai vérifié ces écritures à l’aide de recommandations émises par Intel et les écritures respectent les paramètres recommandés.
La deuxième chose à noter est que le script doit télécharger une base de données SQLite3 à partir d'un projet appelé MCExtractor. Je ne connais pas le projet MCExtractor et je n’ai pas encore vu son code source. N'ayant pas vraiment envie de lancer un autre projet juste pour exécuter ce script, j'ai cherché sur Internet pour voir s'il y avait un danger à accéder à sqlite3 dbs depuis une source inconnue. Il existe en effet n exploit qui peut être réalisé avec sqlite3 appelé Magellan mais il semble être plus lié à l'aspect d'exécution du code de requête de sqlite3 qu'à son aspect db. Personnellement, je ne m'inquiète pas trop pour cela, mais je pensais indiquer la possibilité et vous laisser en faire ce que vous voudriez. L'exploit a été corrigé à partir de SQL 3.26 qui n'est pas encore dans les dépôts Ubuntu Bionic ou Cosmic. Si cela vous inquiète, vous pouvez télécharger la version 3.26 de libsqlite3 directement à partir de http://us.archive.ubuntu.com/ubuntu/pool/main/s/sqlite3/ en tant que fichier deb et l'installer en utilisant Sudo dpkg -i name-of-deb-here.deb. Je recommanderais de rétrograder juste après (encore une fois, en utilisant un fichier deb du même endroit) que la version 3.26 actuellement classée comme instable dans les changelogs.
Ces informations concernent engagez d7d2e69 du projet que vous pouvez trouver dans ce lien .
Il a été réalisé le 11 décembre 2018 et le script sha256 du script de cette version est le suivant: b0f884be51f0eb49ed61854f0e011a2f89f44c35699e07a705b0ec6f98fa29b5
Et vous utilisez probablement github