Ceci est une archive de l'ancien forum de Numerama. Il n'est plus accessible. Vous êtes probablement arrivés ici par erreur. Cliquez ici pour revenir sur la page d'accueil.

Failles Meltdown et Spectre (KPTI, KASLR)

T82135 le 03/01/2018 à 08:57

Tous les processeurs x86-64 de ces 10 dernières années seraient touchés, problème impossible à corriger via le micro-code, de 5 à 30% de pertes de performance prévu…

Les détails sont encore sous embargo mais les patch Linux et Windows sont prêts.

Édit :
Article Numerama https://www.numerama.com/tech/318251-faille-critique-sur-les-processeurs-intel-quelles-seront-les-consequences.html

Edit 2 : sujet renommé

T82135 le 03/01/2018 à 09:04

https://lkml.org/lkml/2017/12/18/1523

Pollux1 le 03/01/2018 à 09:55

Tu es en avance sur Numerama qui a titré sur le jour où il va falloir rebooter tout le cloud :joy: (mais qui ne rentre pas dans les détails techniques de cette faille car c’est un peu compliqué à expliquer re-:joy:)

liolfil le 03/01/2018 à 11:02

Perso c'est via cet article de blog que j'ai découvert l'affaire http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table (via lobsters pour changer hein). J'attends de voir ce qu'il va se passer plus précisément.

T82135 le 03/01/2018 à 11:29

en effet, il y a pas mal de spéculations pour l'instant. Il va falloir attendre encore un pour savoir quel sera réellement l'impact de ce défaut de conception.

T82135 le 03/01/2018 à 14:16

Discussion à ce sujet sur linuxfr.org :

http://linuxfr.org/users/pied/journaux/ca-sent-pas-bon-chez-intel

Le benchmark de Phoronix avec un noyau linux patché :

https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1

T82135 le 03/01/2018 à 22:11

Le communiqué de presse d’Intel :

L’embargo prendra fin le 9 janvier.

La vulnérabilité elle-même CVE-2017-5715 :

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715

Elle n’est pas spécifique à Intel et sera corrigée via mise à jour du micro-code.

Article Nextinpact à ce sujet (réservé aux abonnés pour l’instant) :

anon75590001 le 03/01/2018 à 22:46

Niveau performances, c'était plutôt de l'ordre de 0.28% avec le patch KAISER, et c'est même pas du micro-code (et KASLR renaît de ses cendres).

Reste à attendre la comm des autres constructeurs... et la levée de ce foutu embargo.

T82135 le 04/01/2018 à 07:23

Le site internet de la Graz University of Technology à propos de ces failles (Meltdown et Spectre) :
https://spectreattack.com/

Il y a même des logo :

Les parades mise en place et en développement pour Firefox :
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

T82135 le 04/01/2018 à 07:40

Les processeurs ARM touchés :

Les processeurs IBM System Z, POWER8 (Big Endian and Little Endian), et POWER9 (Little Endian) sont également concernés :
https://access.redhat.com/security/vulnerabilities/speculativeexecution

Le patch pour le noyau Linux 4.15 :

Defender le 04/01/2018 à 08:57

MErci pour le lien :wink:

T82135 le 04/01/2018 à 09:13

Pas content le Torvalds :

https://lkml.org/lkml/2018/1/3/797

T82135 le 04/01/2018 à 22:10

Communiqué d’OVH :

Rien de neuf, ils préviennent qu’il risque d’y avoir des régressions et pertes de performance.

liolfil le 05/01/2018 à 01:14

Communication d’Online, au vitriol vis-à-vis d’Intel

T82135 le 05/01/2018 à 08:39

En attendant, je ne trouve pas dans l’interface (scaleway) la version du “bootscript” qu’ils conseillent d’utiliser.
Ça va se finir en installation manuelle je pense.

T82135 le 05/01/2018 à 11:23

D’autres benchmarck de Phoronix sur plusieurs noyaux Linux avec le patch KPTI activé ou non (Intel Core i7 4790K Haswell). On ne voit pas de baisse de performance vraiment significative.

https://www.phoronix.com/scan.php?page=article&item=linux-kpti-pcid&num=3

Par contre, sur Apache, les noyaux les plus récent sont moins performants (patchés ou non).

Les mise à jours pour Ubuntu sont prévues pour le 9 :

Sur Debian Meltdown est déjà corrigé mais je n’ai rien vu dans les dépôts.

https://security-tracker.debian.org/tracker/CVE-2017-5754

anon75590001 le 05/01/2018 à 15:13

Cette nuit, j'ai passé une stable (chez online.net) en linux-image-4.9+80+deb9u2. Le bug report contenait une 20aine de références à KAISER. Maintenant, ça en est à 4.9+80+deb9u3. 'sont déchainés les mecs...

Et pour unstable.

Faut pas paniquer, c'est pas comme si t'allais choper un virus dans 5 minutes non plus ;)

T82135 le 05/01/2018 à 15:22

Non, non, ça va :sweat_smile:

C’est juste que je ne comprenais pas comment était dénommés les noyaux côté Debian (j’ai pigé maintenant je crois).
Quand je fais un “apt-cache search linux-image” il n’y a pas la numérotation complète des noyaux et du coup je ne savais pas ou j’en étais.
Je pensais que les mises à jour du noyaux étaient proposée via apt avec les autres mises à jour de sécurité ou de paquet mais apparemment ce n’est pas le cas.

mkey le 05/01/2018 à 16:50

Si tu veux le détail d’un package, tu peux servir de apt-cache show [package].

Si c’est bien le cas. Toutefois, les mises à jour majeures doivent être explicitement installées via apt-get dist-upgrade

T82135 le 05/01/2018 à 17:03

Merci.

Par contre, j'ai bien fait un "apt dist-upgrade" et ce ne m'a pas proposé de passer du 4.9.0-3 au 4.9.0-5. Je ne pense pas que apt-get ait un comportement différent mais je n'ai pas testé.

Defender le 05/01/2018 à 18:51

Ouais mais là ils grattent fort, (si, si) et pour l’instant “toute va bene”, j’en ai profité pour mettre à jour :smiley:

liolfil le 05/01/2018 à 20:20

Il ne s'agit que d'Intel pour l'instant. Je cite l'e-mail que tu as aussi reçu:

Important note 2: We are currently gathering information related to the exact scope of the vulnerabilities on ARM based servers. At the moment, we believe that the ARM architecture is only affected by one of the three vulnerabilities. We will communicate as soon as we have more informations.


Intel Meltdown bug mitigation in master (DragonFly BSD)

T82135 le 05/01/2018 à 21:43

Merci, je n’avais pas compris cette note comme ça, je suis resté
bloqué sur le "At least one of your server is impacted by these vulnerabilities and should be upgraded to a more recent kernel version as soon as possible."
En plus c’est indiqué en suite “We released a 4.14.11 Kernel bootscript so every Scaleway customer can move to a fixed kernel against Meltdown on Intel based servers

junius le 05/01/2018 à 22:28

Quelqu’un a écrit un POC pour Spectre je crois (moi j’y connais rien) : https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6

Qu’en pensez-vous ? Qu’en concluez-vous ?

T82135 le 06/01/2018 à 09:08

petitepoupee11 le 06/01/2018 à 14:45

Le test est positif chez moi sous Windows 10 Pro avec le WSL (Windows System for Linux) sur un Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz

junius le 06/01/2018 à 17:18

Dans les commentaires : “From what I see this PoC tries to read the secret from within its own process address space. The virtual address of the other process, even when passed as the first argument would mean nothing for the process executing this exploit.”

Donc le POC lit quelque chose qu’il devrait pas pouvoir lire mais dans son propre processus, pas celui des autres.
C’est rassurant, néanmoins techniquement parlant est-ce que ça veut dire qu’un script exécuté dans le navigateur peut lire tout le contenu du processus navigateur ?

T82135 le 06/01/2018 à 17:41

Voici une vulgarisation du principe exploiter par la faille Meltdown (en anglais) :

En théorie, il peut même lire plus que ça. Firefox a été mis à jour en conséquence d'ailleurs :

https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

anon75590001 le 06/01/2018 à 19:59

Il n'a rien écrit. C'est la copie presque exacte du code d'exemple fourni en annexe du PDF décrivant Spectre.

Une analyse approfondie révèle que ce Erik August Johnson s'est simplement contenté de copier-coller le code d'exemple. Il l'a probablement fait dans son éditeur favori, lequel a vraisemblablement reformaté quelques détails :

  • Essentiellement des white-spaces ajoutés/supprimés au niveau syntaxique. Aucun problème pour C, si ce n'est (comme l'a signalé un commentaire) un problème avec certains compilateurs qui refusent un #define CACHE_HIT_THRESHOLD(80) sans espace entre le nom et la parenthèse ouvrante (parenthèse d'ailleurs inutile dans le code original, mais passons).
  • Une erreur à la fin en remplaçant ce qui devrait être un caractère '?' par une chaîne "?". Heureusement pour lui, c'est sans incidence non plus, bien que ça génère un warning supplémentaire légitime puisqu'il s'agit d'une erreur de correspondance de type avec le format de printf (%c veut dire caractère et donc on doit fournir un argument caractère avec ').

Ça, c'était pour la forme car d'une part, je déconne pas avec C, moi, et d'autre part, j'aime mettre en évidence les copie-colleurs (même s'il reste possible qu'il ne soit pas question de s'approprier un quelconque mérite, mais simplement parce que quelqu'un devait finir par le mettre sur github... je trouve juste dommage que ça n'ait pas été fait de manière rigoureuse et professionnelle).

Sur le fond, l'exemple est correct.

Perso, mon poste de travail principal est un "AMD FX(tm)-8350 Eight-Core Processor" et le test est négatif avec la valeur par défaut 80 pour CACHE_HIT_THRESHOLD, mais positif avec 180. Chier.

Oui.

La solution de Mozilla consiste simplement, pour l'instant, à augmenter la granularité des timers en haute-précision, ce qui empêche l'exploitation de la faille qui repose essentiellement sur le calcul précis de la durée pour lire une donnée (et ainsi deviner quelles cache-lines ont été chargées au niveau micro-architectural, avant les checks de permission).

Perso, je trouve aberrant qu'on puisse faire ça en Javascript. On se prend le JIT très efficace en pleine gueule.

Des solutions comme NoScript sont plus que jamais vitales.

junius le 06/01/2018 à 21:08

Mais c'est la m... avec un grand m... là!

On va quand même pas rester sans javascript éternellement. Et en plus le nouveau noscript est vraiment merdique sur firefox quantum.

Donc, si j'étais un peu malin je pourrais poster du code javascript dans un message de ce forum et piquer tous vos logins et même tout l'historique de vos navigateurs ? Ici même ?

Heureusement que je suis pas malin.

ps : microsoft a sorti un script powershell : https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in

T82135 le 06/01/2018 à 21:26

Merci pour l’analyse !

Qu’est-ce que ça donne quand c’est négatif ?

J’ai un résultat positif avec un Intel Core I5 M430 et sur un Intel Atom CPU N2800 j’ai :
Reading 40 bytes:
Illegal instruction

C’est une erreur ou un résultat négatif ?

anon75590001 le 06/01/2018 à 23:08

Non, tu ne peux pas poster de JS sur Numerama, même du simple HTML ici-même dans les commentaires est fortement limité. Aucun forum ne permet à n'importe qui de poster du JS qui sera automatiquement lancé par le navigateur (à la limite des sites spécialisés dont c'est la fonction, mais même là généralement c'est encadré et relativement sécurisé).

Ça dépend. En ce qui me concerne (et avec CACHE_HIT_THRESHOLD à 80), chaque ligne affiche quelque-chose de cet ordre :

Reading at malicious_x = 0xffffffffffdfecf8... Success: 0xFF=’?’ score=0

Quelqu'un d'autre a eu ça :

Reading at malicious_x = 0xffffffffffdfeb68... Unclear: 0x0A=’?’ score=58 (second best: 0x06 score=58)

Dans tous les cas négatifs, le caractère affiché est '?', mais un seul test négatif n'est pas suffisant pour affirmer qu'on est immunisé, il faut tester différentes valeurs pour CACHE_HIT_THRESHOLD ! Par ailleurs, ne pas simplement se référer au message "Success" ou "Unclear", ce n'est pas fiable. Le score non plus (d'ailleurs, s'il est == 0, la logique de comparaison avec les autres scores affiche "Success", c'est trompeur).

Pour le positif, ça donne la chaîne du source verticalement ("The Magic Words are Squeamish Ossifrage.", comme tu as peut-être pu le voir avec ton I5, il y a aussi des screenshots et des copier-coller dans les commentaires). Un AMD Opteron est positif à 80 apparement, mais il y en a probablement d'autres.

Exception... Il faudrait debugger pour savoir où ça se vautre (un petit coup de gdb ?). Essaye de compiler sans optimisations ou avec.

NB. : Je précise quand-même que l'exemple n'est que, strictement, un POC de la faille. En fait, il devine la chaîne dans la mémoire même du processus, ce qui ne présente pas de danger particulier. Mais c'est l'implémentation de l'exploit qui ne lit pas directement la mémoire, mais indirectement via les timings de cache et l'exécution spéculative. L'exploit "devine", en quelque-sorte. Si c'est positif ici, ça le sera aussi bien pour lire la mémoire protégée du kernel (mais encore faut-il savoir où lire, 'spa...).

anon75590001 le 07/01/2018 à 00:20

J'ai corrigé mon post car mon AMD est positif avec CACHE_HIT_THRESHOLD = 180.

Changez cette valeur si vous n'avez pas la chaîne. Essayez en ajoutant 100 à chaque fois. Je dirais qu'à partir de 1000, vous être tranquille. Si le CPU est exposé, une valeur trop basse ou trop haute sera un test négatif, mais il devrait y avoir une bonne marge au milieu où ce sera positif (par exemple, mon AMD commence à être positif à partir de ~120 et finit à partir de ~400).

Je répète et précise la valeur du POC : un test positif à coup sûr est la chaîne "The Magic Words are Squeamish Ossifrage." affichée verticalement au milieu des lignes. Tout autre résultat avec '?' est peut-être négatif et il faut tester avec d'autres valeurs pour CACHE_HIT_THRESHOLD.

Si la faille est possible sur un modèle donné, aux abords de la marge, il y aura des résultats partiels pour chaque ligne (qui correspond donc à un caractère de la chaîne), ce qui veut dire que vous êtes proche du timing idéal (réduire alors les offsets de valeur pour refaire le test, un peu comme quand on règle une fréquence radio : un peu brouillé sur les bords, net au milieu) et que de toute façon, s'il devine même un seul caractère, c'est déjà mauvais signe. J'imagine qu'à terme, on aura un joli tableau statistique des modèles de CPU avec des marges de timings plus ou moins larges qui seront bien utiles pour les black hat...

J'ai bien envie de forker pour en faire une version qui retourne un résultat plus sûr (en faisant des tests en boucle avec des valeurs différentes pour CACHE_HIT_THRESHOLD et en retournant un message plus clair), mais d'autres le feront probablement (si c'est pas déjà fait).

Mon "AMD FX(tm)-8350 Eight-Core Processor" avec 180 :

Reading 40 bytes:
Reading at malicious_x = 0xffffffffffdfecf8... Success: 0x54=’T’ score=2    
Reading at malicious_x = 0xffffffffffdfecf9... Success: 0x68=’h’ score=2    
Reading at malicious_x = 0xffffffffffdfecfa... Success: 0x65=’e’ score=2    
Reading at malicious_x = 0xffffffffffdfecfb... Success: 0x20=’ ’ score=2    
Reading at malicious_x = 0xffffffffffdfecfc... Success: 0x4D=’M’ score=2    
Reading at malicious_x = 0xffffffffffdfecfd... Success: 0x61=’a’ score=2    
Reading at malicious_x = 0xffffffffffdfecfe... Success: 0x67=’g’ score=2    
Reading at malicious_x = 0xffffffffffdfecff... Success: 0x69=’i’ score=2    
Reading at malicious_x = 0xffffffffffdfed00... Success: 0x63=’c’ score=2    
Reading at malicious_x = 0xffffffffffdfed01... Success: 0x20=’ ’ score=2    
Reading at malicious_x = 0xffffffffffdfed02... Success: 0x57=’W’ score=2    
Reading at malicious_x = 0xffffffffffdfed03... Success: 0x6F=’o’ score=2    
Reading at malicious_x = 0xffffffffffdfed04... Success: 0x72=’r’ score=2    
Reading at malicious_x = 0xffffffffffdfed05... Success: 0x64=’d’ score=2    
Reading at malicious_x = 0xffffffffffdfed06... Success: 0x73=’s’ score=2    
Reading at malicious_x = 0xffffffffffdfed07... Success: 0x20=’ ’ score=2    
Reading at malicious_x = 0xffffffffffdfed08... Success: 0x61=’a’ score=2    
Reading at malicious_x = 0xffffffffffdfed09... Success: 0x72=’r’ score=2    
Reading at malicious_x = 0xffffffffffdfed0a... Success: 0x65=’e’ score=2    
Reading at malicious_x = 0xffffffffffdfed0b... Success: 0x20=’ ’ score=2    
Reading at malicious_x = 0xffffffffffdfed0c... Success: 0x53=’S’ score=2    
Reading at malicious_x = 0xffffffffffdfed0d... Success: 0x71=’q’ score=2    
Reading at malicious_x = 0xffffffffffdfed0e... Success: 0x75=’u’ score=2    
Reading at malicious_x = 0xffffffffffdfed0f... Success: 0x65=’e’ score=2    
Reading at malicious_x = 0xffffffffffdfed10... Success: 0x61=’a’ score=2    
Reading at malicious_x = 0xffffffffffdfed11... Success: 0x6D=’m’ score=2    
Reading at malicious_x = 0xffffffffffdfed12... Success: 0x69=’i’ score=2    
Reading at malicious_x = 0xffffffffffdfed13... Success: 0x73=’s’ score=2    
Reading at malicious_x = 0xffffffffffdfed14... Success: 0x68=’h’ score=2    
Reading at malicious_x = 0xffffffffffdfed15... Success: 0x20=’ ’ score=2    
Reading at malicious_x = 0xffffffffffdfed16... Success: 0x4F=’O’ score=2    
Reading at malicious_x = 0xffffffffffdfed17... Success: 0x73=’s’ score=2    
Reading at malicious_x = 0xffffffffffdfed18... Success: 0x73=’s’ score=2    
Reading at malicious_x = 0xffffffffffdfed19... Success: 0x69=’i’ score=2    
Reading at malicious_x = 0xffffffffffdfed1a... Success: 0x66=’f’ score=2    
Reading at malicious_x = 0xffffffffffdfed1b... Success: 0x72=’r’ score=2    
Reading at malicious_x = 0xffffffffffdfed1c... Success: 0x61=’a’ score=2    
Reading at malicious_x = 0xffffffffffdfed1d... Success: 0x67=’g’ score=2    
Reading at malicious_x = 0xffffffffffdfed1e... Success: 0x65=’e’ score=2    
Reading at malicious_x = 0xffffffffffdfed1f... Success: 0x2E=’.’ score=2
junius le 07/01/2018 à 17:15

C’est vrai, j’avais pas pensé à ça. Bon, c’est déjà ça.

Radamanthe puisque tu as l’air d’être un programmeur, tu penses que ce serait possible de faire un POC en javascript qui affiche l’historique du navigateur ?

anon75590001 le 07/01/2018 à 20:35

PDF décrivant Spectre, section 4.3 :

Ce n’est que le coeur pour exposer la faille, après il faut étoffer pour l’exploiter réellement (ie. sonder l’état des cache-lines).

bactisme le 08/01/2018 à 14:06

D'après ce que je comprend et ce que j'ai lu... la faille est (quasi) inexploitable en JS car les browser ne permette pas aujourd'hui d'être assez précis dans le timing de l'attaque
(pour rappel il s'agit quand même de lire un cache processeur pendant que l'on met le processeur en erreur... on a pour cela que quelque tics tacs d'horloge processeur ...)

(par contre, apparement, certain essaye de glisser cela dans des libs en profitant du peu de control des paquet npm)

anon75590001 le 08/01/2018 à 14:35

Bonne blague :

Même pas besoin du compteur de cycles hardware... Je rappelle que pour CACHE_HIT_THRESHOLD, la valeur par défaut du PoC est 80 et qu'il faut même la monter sur beaucoup de CPU pour avoir le test positif. On est dans l'ordre des centaines de cycles (ne pas oublier que plus les années passent, plus les mémoires sont lentes par rapport aux CPU).

La trap, c'est Meltdown, pas Spectre.

Ben non, au moment de la trap (pour Meltdown), t'es plus dans le contexte spéculatif justement. T'as largement assez de temps (t'as remarqué la lenteur du débit quand-même ? 503Ko/s pour Meltdown, encore plus lent pour Spectre) pour provoquer le chargement des 256 cache-lines une par une (pour chaque octet) afin de déterminer laquelle est déjà chargée, et c'est donc celle qui correspond à la valeur de l'octet.

bactisme le 08/01/2018 à 14:43

Ok, merci pour les précisions.

De ce que je comprend les navigateurs ont quand même été patchés rapidement, non ?

http://xlab.tencent.com/special/spectre/spectre_check.html et https://www.chromium.org/Home/chromium-security/ssca

anon75590001 le 08/01/2018 à 15:06

Je t’avoue que je ne suis pas trop cette actualité là (je ne suis d’ailleurs pas un expert en sécurité, je touche ma bille en programmation et opérations bas niveau sur les CPU/GPU, j’adore courir après les cycles).

Maintenant, il semblerait que Mozilla ait fait sa part du boulot, et j’imagine que Google avant eux.

Merci pour tes liens. On est toujours dans les tests… et la spéculation, si j’ose dire. Perso, je vais attendre quelques jours, c’est un peu l’ébullition là.

liolfil le 09/01/2018 à 18:46

Meltdown and Spectre

T82135 le 09/01/2018 à 18:46

Le bulletin d’alerte du CERT-FR :

https://www.cert.ssi.gouv.fr/alerte/CERTFR-2018-ALE-001/

T82135 le 10/01/2018 à 12:31

Un script sh pour savoir si son noyaux est vulnérable à Spectre et Meltdown :

Je n'ai pas regardé le code en détail mais ça semble sérieux.
Résumé intéressant dans le "readme" :

Quick summary of the CVEs

CVE-2017-5753 bounds check bypass (Spectre Variant 1)

Impact: Kernel & all software
Mitigation: recompile software and kernel with a modified compiler that introduces the LFENCE opcode at the proper positions in the resulting code
Performance impact of the mitigation: negligible

CVE-2017-5715 branch target injection (Spectre Variant 2)

Impact: Kernel
Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU

CVE-2017-5754 rogue data cache load (Meltdown)

Impact: Kernel
Mitigation: updated kernel (with PTI/KPTI patches), updating the kernel is enough
Performance impact of the mitigation: low to medium

Au passage, les noyaux patché PTI (Meltdown) pour Ubuntu et dérivés sont dans les dépots.

bactisme le 10/01/2018 à 14:56

C'est plutôt sérieux, publié par un mec de la team sécurité d'OVH, donc plutôt pas n'importe qui.
MAIS
Ca ne fait que checker la présence de contres-mesures, patch et microcode, ca ne réalise pas de tests poussés des failles elles-mêmes.

T82135 le 11/01/2018 à 17:08

KPTI + Retpoline Linux Benchmarking On Older Clarksfield / Penryn ThinkPads

https://www.phoronix.com/scan.php?page=article&item=pre-pcid-kptiretpoline&num=1

Ça va de 0% de différences jusqu’à -35% dans les cas extrêmes…

junius le 12/01/2018 à 18:51

Juste une conversation twitter ou un chercher démontre qu'il a pu exploité la faille plus facilement et rapidement que jusqu'ici (enfin je crois) https://mobile.twitter.com/aionescu/status/951530541068660736?p=p

Je sais pas si c'est intéressant ou pas alors du coup je le mets. :slight_smile:

anon75590001 le 12/01/2018 à 22:29

Comme il le dit, c'est Meltdown pour lire la mémoire du kernel. Il dit aussi plus loin (boudiou, que je déteste Twitter pour suivre des conversations, pourquoi diable les branches sont séparées par de si petits traits ?!) qu'il n'a fait que réutiliser les PoC déjà publiés. Bref, au moins lui communique, il ne se dore pas trop la pilule, c'est tout à son honneur... Et il ne s'est pas juste contenté d'un copier-coller des documents officiels, il creuse un peu.

C'est bien plus lent que la vidéo de Meltdown original qui n'est qu'un dump à partir d'un endroit précis. Lui, il va chercher les premières infos intéressantes sur les processus en suivant des pointeurs dans des listes chaînées (donc faut lire différentes zones mémoires) et probablement avec une poignée d'indirections. Au final, c'est plus rapide à terme pour atteindre les données qui valent la peine (car un dump de la mémoire du kernel serait très long, et OSEF de 99%).

Enfin, de toute évidence, son test est spécifique à Windows (non pas que ce soit pas possible sur Linux, juste que la manière dont les systèmes agencent ces données est bien différente).

À noter qu'il utilise la fonctionnalité Intel® TSX qui permet de zapper les exceptions/trap, et donc d'aller encore plus vite (c'était aussi évoqué dans le PDF de Meltdown).

Il ne publie pas son code, mais bon, faut dire que Twitter c'est tout sauf du darknet...

T82135 le 12/01/2018 à 22:49

Intel a diffusé les mises à jour des microcode pour un peu moins d'une vingtaines de processeurs (les plus récents).
Il prétendent avoir couvert 90% des processeurs de moins de 5 ans. C'est bien gentil mais la durée de vie d'un processeur est beaucoup plus longue que cela. On fait comment si on a un processeur plus vieux ?
C'est prévu d'être traité...un jour...
Aucune date d'annoncée :

Customer-First Urgency: By Jan. 15, we will have issued updates for at least 90 percent of Intel CPUs introduced in the past five years, with updates for the remainder of these CPUs available by the end of January. We will then focus on issuing updates for older products as prioritized by our customers.

Ils ont vraiment une gestion merdique de cette crise. Il y a quand même eut un progrès puisque maintenant les info sont accessibles depuis la page d'accueil du site officiel. Avant le 9 janvier, pas un mot, en cherchant "spectre" sur le site, les seuls résultats étaient "HP Spectre", le modèle de PC portable...

Les modèles mis à jour :

T82135 le 18/01/2018 à 15:32

Je ne sais pas si c'est une blague... :

https://skyfallattack.com/

junius le 27/01/2018 à 15:04