Explication de la faille intel (dite spectre)

Factom

Posté le 05/01/2018 à 00:19:29

https://image.noelshack.com/minis/2018/01/4/1515105264-spectre-e1515093908627.png

Je suis pas un expert hardware, ni un expert du bas niveau, je vous partage juste ce que j’ai compris. Si j’ai fait une faute merci de la corriger

Résumé :
En gros, les processeurs actuels pour aller vite essayent de prédire ce qu’il faut faire. Par exemple si un programme est :
Si le nombre de connectés sur le 18/25 est plus grand que 2000 alors j’affiche quelque chose à l’écran
Alors le processeur va commencer à préparer l’affichage pendant que le reste de l’ordi va chercher sur le web si il y a plus de 2000 co, tout simplement pour éviter de perdre du temps à afficher si il faut vraiment afficher. Et si il y a pas 2000 co comme il aura rien affiché c’est pas grave
La faille spectre consiste à leurrer le processeur pour lui faire faire des choses en avance (qu’il effacera pas après (perte de temps)) et ensuite d’aller récupérer les choses qu’il a fait. Miraculeusement il aura eu accès à des endroits que le programme n’a pas accès normalement

Proof of concept :
Le code suivant
if (x < taille_tableau1) then y = tableau2[ tableau1[x] ]
si tu l’exécutes pour pleins de valeur de x qui vont donner True à la condition (en gros des valeurs valides) alors le processeur est habitué a rentrer dans le condition et il va le faire d’office pour gagner du temps. Si maintenant un attaquant donne une valeur de x trop grande, l’ordi va préparer en cache la valeur tableau2[ tableau1[x] ], et le truc qu’il prépare en cache dépends de tableau1[x], il suffit de récupérer le cache pour regarder la valeur que valait tableau1[x]. Pour voir ce qui a été mis en cache on regarde toutes les valeurs de tableau2 et on regarde à quelle vitesse elles se load, si c'est rapidement c'est que c'était en cache (et donc que c'était tableau1[x])

Dommage qu’on puisse plus utiliser cette prédiction de branche, c’est assez utile quand on fait de l’opti, par exemple quand on veut faire un traitement sur une liste triée du type if élément < 50 ça va dix fois plus vite sur des listes triées, et les pertes de perfs sont assez énormes si on dit au processeur d’attendre (ça va que 5 fois plus vite)
J’espère qu’ils continueront à faire du matos qui permette ce genre d’optimisation, ça peut être utile dans le matos ultra spécialisé j’imagine
Whitepaper : https://spectreattack.com/spectre.pdf

Apercite https://spectreattack.com/spectre.pdf

Voila c’est tout, la faille était pas si compliquée en fait

https://image.noelshack.com/minis/2018/01/4/1515104948-1495743579-kagami.png

Factom

Posté le 05/01/2018 à 00:26:13

Hentai

Posté le 05/01/2018 à 00:29:12

Oulala déjà en temps normal je comprend pas ton charabia mais la t'as vu l'heure

https://image.noelshack.com/minis/2017/14/1491484186-risitasueur.png

Factom

Posté le 05/01/2018 à 00:29:37

Oui ça oui

Mais je parle du "principe" qui est assez simple au final

Je parie que la NSA connait depuis longtemps cette faille

J'ai rien pigé à comment ils ont réussit à exploiter ça

https://image.noelshack.com/minis/2016/26/1467335935-jesus1.png

Pseudo supprimé

Posté le 05/01/2018 à 00:29:37

Il me semble que le gros problème c'est surtout Meltdown.

Daenerys

Posté le 05/01/2018 à 00:30:19

Merci khey pour cette explication

Factom

Posté le 05/01/2018 à 00:33:08

Citation de Hentai
Oulala déjà en temps normal je comprend pas ton charabia mais la t'as vu l'heure

Fuck désolé

https://image.noelshack.com/minis/2016/46/1479341443-issou.png

Pour faire simple : le processeur pour aller plus vite il essaye de te devancer tes ordres, donc il prépare discrètement les trucs que tu vas probablement demandé (un servant qui amène ta serviette car t'es partit te doucher sans). Mais si finalement t'en a pas besoin bah il remets pas l'objet à sa place. Donc en regardant l'objet qu'il est allé chercher (il est dispo car il l'a pas reposé dans l'armoire) tu peux avoir des infos que tu devrais pas avoir

(même si c'est pas l'objet mais où il l'a posé, je crois)

Goupix

Posté le 05/01/2018 à 00:35:15

D'accord, mais du coup comment ils récupères ou accèdent aux infos sensibles avec ça?

https://image.noelshack.com/minis/2016/48/1480464158-1474824966-1474551493-1474308964-1473610653-picsart-09-11-06-13-46.png

Leonidas

Posté le 05/01/2018 à 00:36:15

Donc la correction de cette faille c'est de plus autoriser le processeur à faire des calculs en avance et c'est pour ça qu'on annonce 30% de perte en perf ?

Merci pour l'explication kheyou

sI-Iarky

Posté le 05/01/2018 à 00:37:01

C'est bien expliqué je trouve.

https://image.noelshack.com/minis/2017/27/1/1499090504-bravo-l-artiste.png

PingouinAigri

Posté le 05/01/2018 à 00:37:09

Comment une faille aussi conne a pu rester pendant 10 ans ?

https://image.noelshack.com/minis/2016/47/1480064732-1467335935-jesus4.png

Hentai

Posté le 05/01/2018 à 00:39:10

Citation de Factom

Citation de Hentai
Oulala déjà en temps normal je comprend pas ton charabia mais la t'as vu l'heure

Fuck désolé
Pour faire simple : le processeur pour aller plus vite il essaye de te devancer tes ordres, donc il prépare discrètement les trucs que tu vas probablement demandé (un servant qui amène ta serviette car t'es partit te doucher sans). Mais si finalement t'en a pas besoin bah il remets pas l'objet à sa place. Donc en regardant l'objet qu'il est allé chercher (il est dispo car il l'a pas reposé dans l'armoire) tu peux avoir des infos que tu devrais pas avoir (même si c'est pas l'objet mais où il l'a posé, je crois)

Ah merci c'est plus clair

https://image.noelshack.com/minis/2017/02/1484173541-cc-risitas596.png

Factom

Posté le 05/01/2018 à 00:39:29

Citation de Goupix
D'accord, mais du coup comment ils récupères ou accèdent aux infos sensibles avec ça?

Je suis pas du tout sur mais même principe que les buffer overflow je pense. Ton tableau1 est d'une certaine taille, donc si t'accèdes aux cases d'après tu accèdes à des cases mémoires non autorisées, et avec un peu de chance c'est des données sensibles
Le détail de l'attaque fait plusieurs pages, ils utilisent des progs alternatifs pour influencer la où le prog va piocher ses données je crois mais j'ai pas trop trop compris

Factom

Posté le 05/01/2018 à 00:43:10

Citation de Leonidas
Donc la correction de cette faille c'est de plus autoriser le processeur à faire des calculs en avance et c'est pour ça qu'on annonce 30% de perte en perf ?
Merci pour l'explication kheyou

Bah je suis pas sur mais je crois
Les 30% ça me parrait bizarre car des benchmarks de liste triées vs listes non triées montre des perfs qui varient de l'ordre du x10 et interdire au proc de faire les calculs à l'avance multiplie par deux le temps défavorable (en gros liste non triée + calcul en avance est deux fois plus lent que liste + pas de calcul en avance est 5 fois plus lent que liste triée + calcul en avance), mais vu que tu dois pas souvent trier des listes ça doit être en moyenne les 30%, c'est à creuser
Benchmarks : https://stackoverflow.com[...]ay-than-an-unsorted-array

Apercite https://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array

Après ya l'autre meltdown qui se base pas sur ça

https://image.noelshack.com/minis/2016/36/1473263674-jesus5.png

Je sais pas en quoi consiste le patch du coup, désolé

Factom

Posté le 05/01/2018 à 00:45:31

Citation de PingouinAigri
Comment une faille aussi conne a pu rester pendant 10 ans ?

Après c'est peut être ultra dur à exploiter (ou beaucoup plus compliqué que ça) + NSA

https://image.noelshack.com/minis/2017/20/1495032802-1485484836-larry-camoufle.png

Trois team qui ont comme par hasard découvert meltdown en même temps

https://image.noelshack.com/minis/2017/18/1493812942-larry-hasard.png

Deux team seulement pour spectre

Pseudo supprimé

Posté le 05/01/2018 à 00:46:11

Au passages les failles ont été découvertes par Google il me semble, ils ont vraiment une équipe de sécurité béton

Merlin

Posté le 05/01/2018 à 00:47:02

Le pire c'est que tout les Proc courant depuis 1995 son affecté, AMD et ARM aussi.

Factom

Posté le 05/01/2018 à 00:49:08

Citation de Markov

Citation de Factom

Citation de Goupix
D'accord, mais du coup comment ils récupères ou accèdent aux infos sensibles avec ça?

Je suis pas du tout sur mais même principe que les buffer overflow je pense. Ton tableau1 est d'une certaine taille, donc si t'accèdes aux cases d'après tu accèdes à des cases mémoires non autorisées, et avec un peu de chance c'est des données sensibles
Le détail de l'attaque fait plusieurs pages, ils utilisent des progs alternatifs pour influencer la où le prog va piocher ses données je crois mais j'ai pas trop trop compris

Rien à voir. Une attaque par buffer overflow, tu sais exactement combien d'octets utiliser pour saturer esi et edi.

Hmm c'est pas le même principe dans le sens de "dépasser de la zone mémoire qui t'était allouée pour récupérer/injecter des trucs interdits" ? Désolé dans ce cas
Le pavé contient il des fautes ?
Vous, les experts, devraient faire ce genre de topic

Factom

Posté le 05/01/2018 à 01:02:23

Citation de Markov

Citation de Factom

Citation de Markov

Citation de Factom

Citation de Goupix
D'accord, mais du coup comment ils récupères ou accèdent aux infos sensibles avec ça?

Je suis pas du tout sur mais même principe que les buffer overflow je pense. Ton tableau1 est d'une certaine taille, donc si t'accèdes aux cases d'après tu accèdes à des cases mémoires non autorisées, et avec un peu de chance c'est des données sensibles
Le détail de l'attaque fait plusieurs pages, ils utilisent des progs alternatifs pour influencer la où le prog va piocher ses données je crois mais j'ai pas trop trop compris

Rien à voir. Une attaque par buffer overflow, tu sais exactement combien d'octets utiliser pour saturer esi et edi.

Hmm c'est pas le même principe dans le sens de "dépasser de la zone mémoire qui t'était allouée pour récupérer/injecter des trucs interdits" ? Désolé dans ce cas
Le pavé contient il des fautes ?
Vous, les experts, devraient faire ce genre de topic

Dans une attaque par buffer overflow, on fait effectivement littéralement un dépassement de tampon. Le but est d'exploiter la stack d'une fonction vulnérable et de changer l'adresse vers laquelle saute la fonction quand elle a fini. Si tu réussis à rediriger vers l'adresse d'un code de ta composition (par exemple un shell qui serait lancé par root) tu deviens le maitre.
Ici, il s'agit plutôt d'une forme évoluée de cache poisoning. On ne redirige pas le flux du code manuellement. On donne de fausses pistes au processeur pour qu'il ne se doute à aucu moment qu'on va tenter d'accéder à des données sensibles. On lui fait mettre en cache de manière répétée des données inutiles de plus en plus proches de la cible. Au bout d'un moment le cpu prend la décision de mettre en cache un truc plus gros et bingo
Dans les faits c'est un peu plus compliqué. En fait le processeur tente de prédire quand va tomber l'instruction jmp (ou jnz,jne,je,etc). On retrouve ça explicitement dans GoAsm par exemple.
Le but est d'utiliser cette prédiction pour corrompre l'intégrité 'morale' du cpu

Je vois, c'est intéressant

https://image.noelshack.com/minis/2016/50/1481994659-mathematicienrisitas.png

Merci !
Tu voulais où plutôt de quand* pour les jump non ?

Factom

Posté le 05/01/2018 à 01:17:25

Citation de Markov

Citation de Factom

Citation de Markov

Citation de Factom

Citation de Markov

Citation de Factom

Citation de Goupix
D'accord, mais du coup comment ils récupères ou accèdent aux infos sensibles avec ça?

Je suis pas du tout sur mais même principe que les buffer overflow je pense. Ton tableau1 est d'une certaine taille, donc si t'accèdes aux cases d'après tu accèdes à des cases mémoires non autorisées, et avec un peu de chance c'est des données sensibles
Le détail de l'attaque fait plusieurs pages, ils utilisent des progs alternatifs pour influencer la où le prog va piocher ses données je crois mais j'ai pas trop trop compris

Rien à voir. Une attaque par buffer overflow, tu sais exactement combien d'octets utiliser pour saturer esi et edi.

Hmm c'est pas le même principe dans le sens de "dépasser de la zone mémoire qui t'était allouée pour récupérer/injecter des trucs interdits" ? Désolé dans ce cas
Le pavé contient il des fautes ?
Vous, les experts, devraient faire ce genre de topic

Dans une attaque par buffer overflow, on fait effectivement littéralement un dépassement de tampon. Le but est d'exploiter la stack d'une fonction vulnérable et de changer l'adresse vers laquelle saute la fonction quand elle a fini. Si tu réussis à rediriger vers l'adresse d'un code de ta composition (par exemple un shell qui serait lancé par root) tu deviens le maitre.
Ici, il s'agit plutôt d'une forme évoluée de cache poisoning. On ne redirige pas le flux du code manuellement. On donne de fausses pistes au processeur pour qu'il ne se doute à aucu moment qu'on va tenter d'accéder à des données sensibles. On lui fait mettre en cache de manière répétée des données inutiles de plus en plus proches de la cible. Au bout d'un moment le cpu prend la décision de mettre en cache un truc plus gros et bingo
Dans les faits c'est un peu plus compliqué. En fait le processeur tente de prédire quand va tomber l'instruction jmp (ou jnz,jne,je,etc). On retrouve ça explicitement dans GoAsm par exemple.
Le but est d'utiliser cette prédiction pour corrompre l'intégrité 'morale' du cpu

Je vois, c'est intéressant
Merci !
Tu voulais où plutôt de quand* pour les jump non ?

Les deux à la fois
Si tu écris un truc du genre
mov rcx,100000001
boucle:
dec rcx
cmp rcx,0
jnz boucle
Le processeur sait qu'il va devoir se préparer à sauter très souvent à l'adresse désignée par boucle (où)
Et il sait aussi qu'il saute après deux instructions (quand) donc quand il verra dec rcx, il se préparera déjà à éventuellement sauter après le cmp

Okok je vois, c'est instructif merci

https://image.noelshack.com/minis/2017/21/1495823618-risitas596.png

Ça doit être hyper intéressant de design du hardware en évitant de se faire avoir par pleins de pièges

Topic : « Explication de la faille intel (dite spectre) »