Faille Intel

Justement, ici c’est rendu possible car chaque processus voit son espace d’adressage investi par le noyau. Et je me demande si, justement, avec une architecture à micro-noyaux, on aurait pu éviter cette règle qui stipule que chaque processus aie dans sa table de pages mémoires l’ensemble d’un noyau monolithique. Ici on palie le problème avec KPTI, mais est-ce qu’avec une archi micro-noyau on aurait pu éviter le problème en amont "by design" et par conséquence évité de se retrouver du jour au lendemain avec des problèmes d’impacts soudains de performances.

D’ailleurs, vous trouvez pas ça bizarre qu’on ne parle pas de BSD ? Est-ce qu’un tel noyau est impacté par ces attaques ? Taurre, si jamais tu passes par là…

Les pages mémoire du noyau ne sont pas dans la table de pages mémoires de chaque processus, c’est une table à part, mais que le processeur connais quand même. De fait, le micro-noyau ne change rien pour l’accès à la mémoire noyau. Par contre, comme les données sont rarement dans le noyau, elles sont plus rarement mappées sur micro-noyau; mais ça veut aussi dire qu’il y a un flush du TLB (le cache de la MMU) à chaque fois qu’on passe d’un contexte à un autre, ça a le même coût en performance que les mesures de containement qu’on va mettre en place sur Linux (parce que c’est finalement la même opération, qui ne serait normalement pas requise sur un noyau monolithique). Ah, et du coup, le cas de BSD n’a aucune raison de différer de celui des autres noyaux.

Le correctif de ces failles, aujourd’hui, c’est d’aligner le temps d’exécution de tous les cas sur le pire cas pour qu’on ne puisse pas déduire le chemin d’exécution à partir du temps d’exécution. A plus long terme, ARM propose déjà des instructions de barrière interdisant l’exécution prédictive, permettant ainsi de délimiter finement les zones où on limite volontairement les perfs. Globalement, un attribut mémoire "No prediction", semblable au "Never eXecute" actuel, devrait être une bonne solution pour protéger les données. La plupart des données du noyau ne sont pas secrètes (en premier lieu son code), ça devrait limiter l’impact sur les performances.

Les pages mémoire du noyau ne sont pas dans la table de pages mémoires de chaque processus, c’est une table à part, mais que le processeur connais quand même.

Cela veut dire qu’il existe une table à part mais qu’elle reste partagée par tous les processus ? Pour éviter de la dupliquer dans chaque "directory" des processus ?

Salut,

À l’heure actuelle, je n’en sais strictement rien. ^^"

Si je ne dis pas de bêtises, les différents *BSD (en tous les cas certainement pour OpenBSD) n’ont pas bénéficiés de l’information sous embargo, ils ont donc découverts la faille un peu près en même temps que le grand public (édit : à supposer qu’ils n’étaient pas déjà au courant d’une autre manière, cf. plus bas). Du coup, je pense que cela grouille en coulisse pour déterminer l’impact exact de ces failles (édit : ou pas ). Côté OpenBSD, à ma connaissance, il n’y a pas encore eu d’information officielle de la part de l’équipe technique malgré deux courriels sur les listes de diffusions @misc et @tech (ce qui me fait dire qu’il planche sur la question actuellement).

Dans tous les cas, s’agissant d’une faille matérielle, il n’y a pas de raisons qu’ils ne soient pas vulnérables à Spectre. Pour Meltdown, par contre, il faudra attendre une réponse officielle.

Édit : mmm… Il semble que certains aspects du problème présenté récemment aient déjà été pointé du doigt quelques années auparavant…

Est-ce qu’un tel noyau est impacté par ces attaques ?

Tous les OS sont impactés à la base puisque c’est un défaut hardware ! Si Mac n’est pas concerné aujourd’hui par Meltdown, c’est parce qu’ils en ont été avertis bien plus tôt et l’ont corrigée tout de suite.

Sur le forum de FreeBSD, il a été dit qu’elles ne leur ont été reportées qu’en Décembre et non, contrairement aux autres, en Juin. De plus les systèmes BSD ont également des moyens (humains et financiers) bien plus faibles donc ils auront certainement bien du retard sur les autres (Linux, Windows et Mac). Et puis BSD n’est certainement pas la priorité pour les fondeurs non plus.

Oui. Si le noyau fait une allocation (kmalloc), il faut en garder la trace quel que soit le processus en cours d’exécution, puisqu’il est prévu que toute exécution de code noyau peut accéder à la mémoire noyau, et qu’on ne peut donc pas anticiper quels systèmes auront besoin d’accéder à cette mémoire. On pourrait séparer les différents sous-système du noyau, avec leur propre zone mémoire, et passer par des mécanismes de communication inter-parties pour passer de la mémoire d’un composant à un autre (par exemple pour passer les informations réseau au décodeur H264, pour faire du streaming), mais on aurait alors développé un micro-noyau…

Mémo : Selon ce site faire :

grep bugs /proc/cpuinfo si on a insecure_cpu c’est bon, sinon, ça pue pour nous

ça pue pas tant que ça, la faille ne fait que faire fuiter des informations, du coup, il faut que quelqu’un fasse tourner un code malveillant sur ma machine pendant que j’ai une clef de chiffrement en mémoire, ou le mot de passe d’un site (qui n’aura pas d’intérêt pour l’attaquant, sauf s’il chope celui de ma banque), et qu’il parvienne à cibler la mémoire contenant ma clef, et ensuite s’envoyer le résultat pour me nuire. C’est très improbable. La faille est beaucoup plus intéressante à exploiter sur des serveurs partagés, virtualisés, où la faille est plus simple à exploiter, et potentiellement plus rémunératrice.

De mon côté, ce qui m’inquiète plus ce sont les éventuelles pertes de performances, surtout côté serveur… Le chiffre de 10% circule, mais cela reste un peu flou tant que maintenant.

Meltdown peut également être employée pour réaliser une élévation de privilège. Quant à Spectre, cela peut passer assez inaperçu via l’exécution de Javascript. Bon, je ne dis pas que c’est d’une simplicité enfantine, mais le risque est là. Depuis vingt ans…

Le whitepaper ne parle "que" d’un dump de toute la mémoire mappée. T’as une source sur l’utilisation de la faille pour écrire des données dans un espace mémoire protégé ou exécuter du code arbitraire avec un niveau de privilège usurpé ?

Je pense que Taurre fait référence au fait de combiner Meltdown à une vulnérabilité logicielle au niveau du noyau pour utiliser ROP (KASLR étant contourné vu qu’on arrive à prédire les adresses dans le noyau) et mener une exploitation au niveau du noyau, d’où l’élévation de privilège. Chose a priori difficile voire impossible sans Meltdown à cause de KASLR.

Ge0 m’a devancé.

Pour en revenir à OpenBSD, il est bel et bien vulnérable à Meltdown, une réponse de l’équipe technique a été publiée hier. Comme précisé, les différents *BSD n’ont pas bénéficié d’informations sous embargo et ont donc tous découverts et/ou préssentis le problème via le remue-ménage causé par l’ajout du patch dédié au noyau Linux.

Le message relatif à cette faille publié par l’équipe de DragonFly BSD est également intéressant et moins tendre à l’égard d’Intel.

Je remonte un peu ce sujet, il y a maintenant des patchs pour les deux failles (même si on ne sait pas s’ils sont nickels). Ars Technica a fait un article intéressant pour expliquer leur impact :

https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the-spectre-and-meltdown-patches-will-hurt-performance/

Tiens, j’ai le droit à cpu_meltdown spectre_v1 spectre_v2 à la place de cpu_insecure quand je fais cat /proc/cpuinfo

J’ai quand même cpu_insecure avec la 4.13.0-26, avec en prime des régressions :/

J’ai un noyau 4.14.13, ce qui explique sans doute la différence.

On n’a pas fini d’en entendre parler, les travaux qui ont mené à la découverte de Spectre et Meltdown auraient permis de trouver deux autres failles Skyfall et Solace pour l’instant sous embargo. Il nous faudra donc attendre plus d’infos de la part de Intel, Google ou autre.

Depuis la hype causée par Heartbleed maintenant la sécurité informatique c’est faire du marketing sur une vuln en lui trouvant un nom qui claque et un logo, toujours pour apporter plus de crédit à un groupe de pécores qui se branlent dessus. À croire que ça les arrange qu’il y ait des défauts de sécurité dans nos processeurs. Ce qui est assez contradictoire pour des gens qui se réclament "white hat" (même ce terme est assez bullshit au final) et qui sont supposés espérer que le matériel et les logiciels que nous utilisons soient safe.

Pitoyable…

Dans ma boite, on appelle ça la sécurité par le buzz. En général le client refuse de déployer les mises à jour, parce que c’est compliqué, couteux et risqué, mais si la faille passe dans la presse généraliste, la correction devient ultra-prioritaire, indépendamment de sa gravité et de son exploitabilité.

C’est un problème sous jacen(t).

Ce n’est pas le cas que des clients malheureusement. Souvent les contres mesures ne sont appliquées que si le problème est suffisamment "public". Donc générer un "buzz" autour d’une faille fait que tout le monde se bouge le cul.