Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 30 sur 53
  1. #1
    Coin Coin la communauté X86,

    merci de m'avoir accepté dans vos rangs !

    J'ai eu beau chercher, je n'ai pas trouvé un topic qui parle des différentes failles connus des produits et c'est assez dommage car vraiment très intéressant. Bon ok, parfois c'est hard à comprendre .

    J'ouvre le "bal" avec la dernière faille trouvé sur de très nombreux processeurs Intel au niveau de la mémoire SSM du processeur.

    L'article en anglais => https://www.blackhat.com/docs/us-15/...Escalation.pdf

    Un article en français pas trop mal, bien qu'assez simpliste => http://www.numerama.com/magazine/338...seurs-x86.html

    Bon j'avoue que j'imagine difficilement comment utiliser ça pour faire une attaque de "masse" mais cela reste vraiment impressionnant que cela soit passé sous le radar de tous le monde aussi longtemps...
    Citation Envoyé par Oldnoobie Voir le message
    Salut Charlot, Ton stick m'intéresse énormément, je te MP.

  2. #2
    L'exploit est joli, mais leur deuxième tentative (exécuter les registres APIC comme du code x86) était encore plus classe. Là ça marche surtout sur un gros coup de bol.

    Mais ce n'est pas vraiment resté "sous le radar". On trouve régulièrement des failles qui permettent de passer en SMM. La gestion de la mémoire physique entre les différents périphériques est tellement complexe et dépend de tellement de constructeurs différents qu'il y a toujours des trous. Genre une PCI Option ROM d'un composant quelconque qui a une faille dans un coin. Vouloir protéger de la mémoire sans vrai mécanisme de protection mémoire, c'est forcément casse-gueule.

    D'ailleurs, il y a 10 ans c'était open-bar, les BIOS n'activaient même pas le bit de protection de la mémoire SMM, d'où des exploits ne nécessitant même pas d'être root :
    http://forum.canardpc.com/threads/17...64#post3158664

  3. #3
    Obligatory rowhammer:

    Quand on lit de façon répétée une ligne (row, ~8KiO) de DRAM, ça a tendance à modifier des bits dans les lignes adjacentes (le papier ISCA, même si c'était un problème relativement connu). Google nous a fait une démo en début d'année sur comment s'en servir pour passer root (http://googleprojectzero.blogspot.fr...g-to-gain.html).

    En général, on considérait qu'il était nécessaire d'avoir clflush pour que rowhammer fonctionne, histoire d'avoir assez d'accès à la DRAM avant que la ligne victime ne soit rafraichie. Mais en fait y'en a pas vraiment besoin puisqu'on peut apparemment observer des bitflips dans javascript (Ars, papier). Il a juste fallu reverse la fonction de hash du L3 pour ne pas avoir à remplir le L3 pour être sûr de virer une ligne. Après, pour exploiter la faille dans javascript, ça me paraît être une autre paire de manche.

    A priori ça a été réparé dans la DDR4 en comptant les accès aux lignes et en rafraichissant les lignes adjacentes si ça ressemble à du hammering. Pour la DDR3 il suffit juste de diviser l'intervalle de refresh par 2 ou 4 :3
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

  4. #4
    Alimentons le topic avec la fameuse faille critique de la techno AMT présente sur les processeurs Intel de gamme pro depuis 10 ans :
    https://www.embedi.com/files/white-p...-is-Silent.pdf

    Alors qu'un attaquant puisse contrôler à distance n'importe quelle machine même éteinte branchée au réseau, et que la faille soit passée inaperçue aussi longtemps, c'est un peu embarrassant. Mais quand on voit la gueule de la faille et la simplicité de l'attaque...

    Ironiquement, c'est probablement la faute à un audit de sécurité qui a demandé au programmeur de changer son strcmp en strncmp...

  5. #5
    Je pense que c'est by design : Si tu as oublié ton mot de passe c'est plus simple. J'imagine que c'est designé comme ça pour qu'Intel contrôle et le HW et le SW, mais vu la tronche du "contrôle" c'était peut-être pas la peine...
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

  6. #6
    Comme on parle déjà des failles Meltdown et Spectre dans tous les autres topics, il est temps que celui-ci s'y mette.

    On a donc différentes attaques par canaux cachés sur la microarchitecture. Elles permettent de contourner les mécanismes de protection mémoire en exploitant les effets de bords d'instructions sur un chemin spéculatif. Notamment les chargements mémoire faits sur le wrong path qui changent l'état du cache. On peut par exemple reconstituer les données à une adresse protégée arbitraire, et ça marche particulièrement bien sur les CPU Intel.

    Au delà des failles proprement dites qui peuvent être patchées au cas par cas, je pense que c'est une remise en cause profonde de la microarchitecture à la papa des années 1990. Les failles n'exploitent pas juste quelques bugs qu'on aurait laissé passé par accident : elles exploitent surtout le fonctionnement normal d'un processeur superscalaire, et elles sont évidentes a posteriori. C'est simplement que jusqu'ici la sécurité de l'information n'entre même pas en ligne de compte pour la plupart des microarchitectes (au moins dans la communauté académique, mais l'existence des failles en question laisse penser que c'est pareil dans l'industrie).

    Mais avec le bruit que fait cette affaire, ça va surement changer. Ça peut avoir l'effet d'un nouveau bug du Pentium, et obliger les architectes à être un peu plus rigoureux et à regarder autre chose que la perf et le power.

  7. #7
    J'avoue que j'ai du mal à mesurer la portée réelle des attaques : on peut faire de l'attaque de masse utilisable sans disposer des moyens de la NSA pour traiter les retours, ou c'est des attaques ciblées et il y a la dernière grille de sûreté, la chance, qui protège pas mal ?

    Et parce qu'il faut bien aider les amis :
    La provence

  8. #8
    La chance ne suffit pas en sécurité, surtout sur un processeur à plusieurs GHz. Même si l'attaque ne sort qu'un seul bit une fois sur un million, tu as tout le temps de récupérer toutes les clés de chiffrement que tu veux en quelques secondes.
    On peut aussi objecter que les attaques sont très spécifiques à un processeur et un superviseur, OS, ou navigateur. Admettons que tu aies fait une attaque qui marche sur Skylake et Windows 10, ou sur Skylake et Firefox, ou sur A10 et iOS... ah bah tu pwnes déjà un parc installé de centaines de millions de machines. Le retour sur investissement d'une attaque c'est le produit nombre de cibles * importance des cibles. Si ce produit est grand, tu trouveras toujours assez de hackers prêts à y passer le temps qu'il faut.

    Une seule faille de ce genre ne suffit pas à faire un Skynet, mais quand tu la combines avec le reste de ton catalogue d'attaques connues, il y a moyen de construire des malwares qui font vraiment chier.

  9. #9
    Oui mais si tu récupères un dump mémoire (32Go sur mon PC perso) de l'ensemble des PC dans le même type de config, tu traites comment pour trouver les clés ?

    Ou alors, l'attaque c'est
    Code:
    if CPUID=="Skylake" && OS.version=="Windows 10" && Browser.version=="Firefox 52.0 64bits" then
    data[]=getdatafromram;
    i=find("Ici ya la clé secrète",data);
    sendtohackerz(data[i]);
    endif;

    Et parce qu'il faut bien aider les amis :
    La provence

  10. #10
    Option 2. Une fois que tu sais où chercher, tu trouves.
    Et pour trouver où chercher, il y a d'autres attaques.

  11. #11
    Au moins on va peut-être arrêter de nous bassiner avec le machine learning à ISCA

    Du grain à moudre sur comment certains designers envisagent de patcher les failles en attendant les "vrais" correctifs (hardware, donc) : Intel, ARM
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

  12. #12
    Citation Envoyé par Møgluglu Voir le message
    Comme on parle déjà des failles Meltdown et Spectre dans tous les autres topics, il est temps que celui-ci s'y mette.

    On a donc différentes attaques par canaux cachés sur la microarchitecture. Elles permettent de contourner les mécanismes de protection mémoire en exploitant les effets de bords d'instructions sur un chemin spéculatif. Notamment les chargements mémoire faits sur le wrong path qui changent l'état du cache. On peut par exemple reconstituer les données à une adresse protégée arbitraire, et ça marche particulièrement bien sur les CPU Intel.

    Au delà des failles proprement dites qui peuvent être patchées au cas par cas, je pense que c'est une remise en cause profonde de la microarchitecture à la papa des années 1990. Les failles n'exploitent pas juste quelques bugs qu'on aurait laissé passé par accident : elles exploitent surtout le fonctionnement normal d'un processeur superscalaire, et elles sont évidentes a posteriori. C'est simplement que jusqu'ici la sécurité de l'information n'entre même pas en ligne de compte pour la plupart des microarchitectes (au moins dans la communauté académique, mais l'existence des failles en question laisse penser que c'est pareil dans l'industrie).

    Mais avec le bruit que fait cette affaire, ça va surement changer. Ça peut avoir l'effet d'un nouveau bug du Pentium, et obliger les architectes à être un peu plus rigoureux et à regarder autre chose que la perf et le power.
    J'ai eu un peu de mal à comprendre ces deux papiers. N'étant pas trés doué en archi.
    Si j'ai bien compris, pour Meltdown c'est basé sur le fait que la différence entre Kernel et user c'est un simple bit qui change séquentiellement durant l’accès à l'un de ces espaces. Mais qu'avec les optimisations "out of order" une partie du code en aval, qui peut etre kernel du coups, va être exécuté préventivement (et pas dans l'ordre du coups ) pour éviter les goulets d’étranglement en amont. Mais sans utiliser la sécurité qui va bien de flip flap de bit. Résultat des courses : du code kernel se retrouve en stand bye dans un bout du CPU et peut être observé par l'utilisateur.
    Je sens que je doit me gourer quelques part ^^. Si tu peut me corriger ^^.

    Pour le second si j'ai bien compris c'est très proche, mais ça utilise le fait que les CPU font de la prédiction sur le futur code exécutable et donc qu'on peut les leurrer. Je n'ai pas forcement capté en quoi ça cause un soucis de sécurité par contre, un peu de mal sur celui ci.

    Dans les deux cas, en quoi ça ne peut pas être évité en désactivant ces optimisation au niveau du firmware du cpu ? Ou alors il est impossible matériellement d’exécuter un code sans ces optims ?

  13. #13
    Citation Envoyé par Nilsou Voir le message
    J'ai eu un peu de mal à comprendre ces deux papiers. N'étant pas trés doué en archi.
    Si j'ai bien compris, pour Meltdown c'est basé sur le fait que la différence entre Kernel et user c'est un simple bit qui change séquentiellement durant l’accès à l'un de ces espaces. Mais qu'avec les optimisations "out of order" une partie du code en aval, qui peut etre kernel du coups, va être exécuté préventivement (et pas dans l'ordre du coups ) pour éviter les goulets d’étranglement en amont. Mais sans utiliser la sécurité qui va bien de flip flap de bit. Résultat des courses : du code kernel se retrouve en stand bye dans un bout du CPU et peut être observé par l'utilisateur.
    Je sens que je doit me gourer quelques part ^^. Si tu peut me corriger ^^.
    Toutes les attaques fonctionnent même si les instructions sont exécutées dans l'ordre. Ce qu'elles exploitent c'est le fait que le processeur prédit la direction des branchements bien avant d'avoir calculé la vraie valeur de leur condition, et commence à exécuter le code sur la branche qu'il estime la plus probable. S'il se goure, il répare l'état architectural du processeur : les registres et les accès mémoire en vol, pour faire comme si le code spéculatif n'avait jamais été exécuté. Néanmoins, il peut rester des traces sous la forme d'effet de bord sur le cache.

    Les attaques ont cette forme-là :
    Code:
    flush_cache();
    if(cond) {
      x = array1[array2[i]];
    }
    probe_cache();
    Le déroulement est le suivant :
    - L'attaquant commence par entrainer le prédicteur de branchements en exécutant le code avec cond qui vaut true, et un index i inoffensif.
    - Puis remplit tout le cache avec des données, genre en parcourant un tableau assez grand.
    - Puis met cond à false, et i calculé pour que array2[i] tombe sur l'adresse secrète qu'on cherche à lire.
    - Le processeur prédit que cond sera vrai comme avant, et commence à exécuter l'intérieur du if. Il accède à la donnée secrète array2[i], et dans la foulée lance un chargement mémoire en l'utilisant comme adresse. La donnée remonte dans le cache. Puis la mauvaise prédiction de branchement est corrigée, mais la donnée est toujours dans le cache.
    - Enfin, on accède de nouveau aux données qu'on avait mis dans le cache, en mesurant le temps que ça prend à chaque fois. Si un élément rencontre un défaut de cache, c'est qu'il a été remplacé par l'élément array1[array2[i]]. Comme tu sais lequel c'est, tu récupères des infos sur l'adresse, c'est-à-dire des bits de array2[i], qui est le secret que tu voulais.

    Dans le cas de Meltdown, la faille des processeurs Intel est qu'ils continuent à exécuter le code spéculatif même si le processus n'a pas le droit d'accéder à array2[i], contrairement à AMD par exemple. C'était considéré comme "pas grave" puisque les architectes considèrent que le code exécuté spéculativement n'a pas d'effet visible niveau architectural.

    Spectre c'est plus vicieux. Tu attaques un branchement indirect dans le kernel, par exemple un appel sur un pointeur de fonction. Tu entraines ton prédicteur indirect pour qu'il saute à une adresse qui correspond par exemple à une instruction load [r1]. Sur le même principe, il se produit un accès spéculatif à [r1], ce qui te permet de récupérer des infos sur la valeur de r1. Et ce coup-ci tu fais exécuter la branche spéculative par le kernel, qui a toutes les permissions qu'il faut.

    tl;dr: c'est la faute à l'IA dans les processeurs.

    Dans les deux cas, en quoi ça ne peut pas être évité en désactivant ces optimisation au niveau du firmware du cpu ? Ou alors il est impossible matériellement d’exécuter un code sans ces optims ?
    Si on désactive la prédiction de branchement et les caches, on retourne à l'age de pierre.

  14. #14
    Citation Envoyé par Møgluglu Voir le message
    Si on désactive la prédiction de branchement et les caches, on retourne à l'age de pierre.
    Pas si sûr. On pourrait faire un processeur avec des coeurs in-order connectés directement sur un bus circulaire par exemple.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  15. #15
    Pourquoi in-order?
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

  16. #16


    Moui en effet j'ai mentalement confusé les problématiques. Veuillez oublier mon message précédent.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  17. #17
    Citation Envoyé par Møgluglu Voir le message
    S'il se goure, il répare l'état architectural du processeur : les registres et les accès mémoire en vol, pour faire comme si le code spéculatif n'avait jamais été exécuté. Néanmoins, il peut rester des traces sous la forme d'effet de bord sur le cache.
    Pourquoi exactement du coups ?
    Si j'ai bien compris, sans cet effet de bord Spectre et Meltdown n'existent plus ...

    Citation Envoyé par Møgluglu Voir le message
    - Le processeur prédit que cond sera vrai comme avant, et commence à exécuter l'intérieur du if. Il accède à la donnée secrète array2[i], et dans la foulée lance un chargement mémoire en l'utilisant comme adresse. La donnée remonte dans le cache. Puis la mauvaise prédiction de branchement est corrigée, mais la donnée est toujours dans le cache.
    - Enfin, on accède de nouveau aux données qu'on avait mis dans le cache, en mesurant le temps que ça prend à chaque fois. Si un élément rencontre un défaut de cache, c'est qu'il a été remplacé par l'élément array1[array2[i]]. Comme tu sais lequel c'est, tu récupères des infos sur l'adresse, c'est-à-dire des bits de array2[i], qui est le secret que tu voulais.
    Pour le premier truc en gras : Du coups en quoi n'est-il pas possible t’intégrer au niveau "firmware" ou même OS le fait d'automatiquement écraser le cache (ou juste les bits dangereux) après ce type d’opération ?
    Pour la seconde partie en gras, pourquoi "comme tu sais lequel c'est", tu peut lire le cache sans soucis à ce stade j'imagine que c'est ce que tu veut dire ?

    J'ai aussi une question plus générale. Pourquoi la sécurité d’accès à une adresse interdite n'est pas activé durant l’exécution de code prédictif ? Ça a l'air con comme question, mais c'est pourtant une faille immense, et je ne comprends pas bien pourquoi elle est présente ... parce que pendant l’exécution du code prédictif il sait bien qu'il accède a une adresse interdite.
    Ou alors c'est parce que l'autorisation pourrait etre donné juste avant le segment prédit donc il le fait quand même. Et qu'il préfère prédire parce que ce genre de cas est trop courant, le désactiver reviendrait à perdre énormément en perf ?
    Dernière modification par Nilsou ; 14/01/2018 à 13h01.

  18. #18
    Citation Envoyé par Møgluglu Voir le message
    Si on désactive la prédiction de branchement et les caches, on retourne à l'age de pierre.
    Néanmoins si c'était possible de l'interdire pour certaines application alors il existe un patch simple à la compilation pour certaines application critique (qui n'aurais rien à faire de la perfs, par exemple).

    Citation Envoyé par Møgluglu Voir le message
    Spectre c'est plus vicieux. Tu attaques un branchement indirect dans le kernel, par exemple un appel sur un pointeur de fonction. Tu entraines ton prédicteur indirect pour qu'il saute à une adresse qui correspond par exemple à une instruction load [r1]. Sur le même principe, il se produit un accès spéculatif à [r1], ce qui te permet de récupérer des infos sur la valeur de r1. Et ce coup-ci tu fais exécuter la branche spéculative par le kernel, qui a toutes les permissions qu'il faut.
    J'ai du mal a capter spectre. Si tu part d'un code s’exécutant dans le kernel (car dans ton exemple le branchement indirect et sa destination load[r1] sont sans le kernel si j'ai bien capté), comment peut tu employer la même stratégie que ce que tu a décrit plus haut. Dans ce que tu a décrit plus haut c'est la faculté qu'a l'utilisateur de mesurer le temps d’accès et de lire la valeur du cache qui joue, donc sa faculté finalement a avoir la mainmise sur le coté utilisateur du code. Ici je vois mal comment ce serait possible puisque qu'il faudrait être dans le kernel pour faire la mesure ... (et que si tu a du code a toi dans le kernel, autant exécuter toi même ce que tu a envie directement ^^)

    Dans les deux cas, ce type de code semble facilement repérable/typique non ? Ne serait-il pas possible de simplement les détecter façon virus ?
    Dernière modification par Nilsou ; 14/01/2018 à 13h14.

  19. #19
    Citation Envoyé par Nilsou Voir le message
    Pourquoi exactement du coups ?
    Si j'ai bien compris, sans cet effet de bord Spectre et Meltdown n'existent plus ...
    Il y a toujours des effets de bords parce qu'on ne sait pas remonter le temps, et pire, parce que le temps linéaire est un mensonge.

    Idéalement, il faudrait restaurer l'état de tous les caches, les buffers internes, et même les row buffers dans les puces mémoires, pour faire comme si la spéculation n'avait jamais eu lieu. Sachant que pendant ce temps les autres threads sur les autres cœurs ont fait quelques centaines ou milliers d'accès mémoire à d'autres endroits ou même au même endroit dans ces caches et buffers. Même si tu arrives à restaurer un tel état, ça n'empêche pas le code spéculatif d'avoir causé des interférences sur les accès mémoire des autres threads, en changeant légèrement leur timing. Ça suffit pour faire fuir de l'information qu'un attaquant pourra récupérer en détectant des petites variations de timing sur des séquences d'opérations bien choisies.

    Pour le premier truc en gras : Du coups en quoi n'est-il pas possible t’intégrer au niveau "firmware" ou même OS le fait d'automatiquement écraser le cache (ou juste les bits dangereux) après ce type d’opération ?
    Si tu agis a posteriori c'est trop tard : tu as du évincer une donnée qui était auparavant dans le cache pour la remplacer par celle que tu as chargé spéculativement, et tu ne sais même plus laquelle c'était. Par contre l'attaquant peut détecter que tu as dégagé la donnée qu'il avait soigneusement placé à cet endroit.

    En agissant a priori au niveau matériel, c'est sûrement possible pour le cache L1 : on pourrait ajouter des buffers pour ne mettre à jour le cache qu'au moment du retirement des instructions. Mais ça ne fait que repousser le problème aux autres caches, L2, L3, et L1 des autres cœurs.
    Par exemple tu peux exploiter le protocole de cohérence de caches pour fuiter de l'info. Quand le core 1 charge une donnée que le core 2 a modifié dans son propre cache, ça peut forcer par exemple le core 2 à mettre à jour le cache partagé avec la version modifiée. Paf, effet de bord visible même si le core 1 change d'avis juste après.

    Pour la seconde partie en gras, pourquoi "comme tu sais lequel c'est", tu peut lire le cache sans soucis à ce stade j'imagine que c'est ce que tu veut dire ?
    Oui, tu parcours ton tableau jusqu'à trouver la différence de timing, l'index que tu obtiens correspond aux bits de poids faibles de la valeur que tu cherches. Tu exploites le fait que sur un cache set-associative, les entrées sont indexée par les bits de poids faible des adresses. Deux adresses qui ont les mêmes bits de poids faibles vont se retrouver en conflit et se battre pour le même set.
    Le code de l'exploit est relativement lisible d'ailleurs :
    https://github.com/IAIK/meltdown/blo...ibkdump.c#L507

    J'ai aussi une question plus générale. Pourquoi la sécurité d’accès à une adresse interdite n'est pas activé durant l’exécution de code prédictif ? Ça a l'air con comme question, mais c'est pourtant une faille immense, et je ne comprends pas bien pourquoi elle est présente ... parce que pendant l’exécution du code prédictif il sait bien qu'il accède a une adresse interdite.
    Ou alors c'est parce que l'autorisation pourrait etre donné juste avant le segment prédit donc il le fait quand même. Et qu'il préfère prédire parce que ce genre de cas est trop courant, le désactiver reviendrait à perdre énormément en perf ?
    Ce point précis, oui, ça semble une connerie, spécifique aux archis Intel et quelques autres.
    Enfin quasiment tout le monde résume Meltdown en "Intel ne vérifie pas les permissions sur le code spéculatif, lol", mais il semble que c'est plus compliqué que ça. C'est plutôt : sous certaines conditions, le processeur va accéder au cache et faire suivre la donnée aux instructions suivantes avant d'avoir vérifié les permissions du TLB. Je soupçonne que ce soit lié à un mécanisme de prédiction de voie agressif, qui accède au données du cache avant même d'avoir la confirmation des tags et du TLB.

    Citation Envoyé par Nilsou Voir le message
    Néanmoins si c'était possible de l'interdire pour certaines application alors il existe un patch simple à la compilation pour certaines application critique (qui n'aurais rien à faire de la perfs, par exemple).
    C'est essentiellement ce que fait Intel pour patcher le kernel contre l'attaque Spectre par injection de code spéculatif : ils ont une moulinette qui marque les branchements considérés comme vulnérables et place des barrières de spéculation qui empêche la prédiction.

    Quelques ordres de grandeur : entre 1 instruction sur 3 et 1 instruction sur 5 est un branchement. Une microarchi moderne a 200 instructions en vol, dont 50 branchements.

    J'ai du mal a capter spectre. Si tu part d'un code s’exécutant dans le kernel (car dans ton exemple le branchement indirect et sa destination load[r1] sont sans le kernel si j'ai bien capté), comment peut tu employer la même stratégie que ce que tu a décrit plus haut. Dans ce que tu a décrit plus haut c'est la faculté qu'a l'utilisateur de mesurer le temps d’accès et de lire la valeur du cache qui joue, donc sa faculté finalement a avoir la mainmise sur le coté utilisateur du code. Ici je vois mal comment ce serait possible puisque qu'il faudrait être dans le kernel pour faire la mesure ... (et que si tu a du code a toi dans le kernel, autant exécuter toi même ce que tu a envie directement ^^)
    C'est ça qui est beau. Tu pilotes du code existant dans le kernel, mais depuis l'extérieur. Par exemple, tu peux :
    1. Entraîner le prédicteur de branchements indirects dans ton code utilisateur non-privilégié : code inoffensif qui ne fait que des sauts indirects genre appels de fonctions virtuelles.
    2. Faire un appel système inoffensif, genre un write sur stdout. L'exécution spéculative se déroule en mode kernel.
    3. De retour en mode utilisateur, tu examines ce qui est présent dans le cache comme pour l'attaque Meltdown. Code inoffensif qui ne fait que des accès tableau (et quelques lectures de timer).

    Dans les deux cas, ce type de code semble facilement repérable/typique non ? Ne serait-il pas possible de simplement les détecter façon virus ?
    C'est ça qui est beau (bis). Le code Meltdown/Spectre 1, c'est un truc de la forme :
    Code:
    unsigned int a[n], b[m];
    if(i < n) {
      x = b[a[i]];
    }
    On a tous déjà écrit ce code pour des raisons totalement légitimes. Il n'y a absolument rien de suspect là-dedans. On peut même ajouter un test que a[i] < m, ça marche toujours.

  20. #20
    Merci pour la réponse, j'ai pas mal appris ^^.

    Autre question que je me posais. Une solution ne serait-elle pas d'uniformiser les temps d’accès ? En insérant des variations de temps aléatoire dans les accès au cache par exemple ? J'imagine que l'OS comme n'importe quelle micro-code bas niveau pourrait le faire sans soucis, et donc interdire, en échange de perfs, la déduction par temps d’accès.

    Pour l'histoire de la déduction en tant que virus. Je pensais au fait que quelque part il va devoir insérer du code pour mesurer les temps d’accès justement. Et du code pour remplir tout le cache ET du code pour le lire en entier.
    L'ensemble doit être possible à détecter ...

    Par ailleurs, il faut aussi que les mecs aient accès à une appli largement distribuée de façon légitime. C'est surement le plus dure ...

  21. #21
    De rien, pardon pour le pavé...

    Citation Envoyé par Nilsou Voir le message
    Autre question que je me posais. Une solution ne serait-elle pas d'uniformiser les temps d’accès ? En insérant des variations de temps aléatoire dans les accès au cache par exemple ? J'imagine que l'OS comme n'importe quelle micro-code bas niveau pourrait le faire sans soucis, et donc interdire, en échange de perfs, la déduction par temps d’accès.
    La raison d'être du cache est de rendre l'accès aux données qui sont dans le cache plus rapides qu'à celles qui n'y sont pas. Si on uniformise les temps d'accès, autant ne pas avoir de cache du tout. Ce n'est pas raisonnable de passer tous les accès de 3 à 300 cycles. Même si ça l'était, il resterait d'autres structures comme les TLB ou les row buffers en DRAM comme canaux cachés exploitables.

    Par contre, plus simplement, tu peux ajouter de l'aléa aux timers pour les rendre moins précis, et donc plus difficile à utiliser pour des mesures de latence. C'est ce qui est fait dans certains moteurs Javascript. Mais ça se contourne : même un timer imprécis suffit pour détecter un biais statistique, moyennant suffisamment de mesures. Même sans timer du tout on peut fabriquer un compteur de temps assez précis avec un thread qui fait un while(1) { i++; } sur un autre cœur.

    Pour l'histoire de la déduction en tant que virus. Je pensais au fait que quelque part il va devoir insérer du code pour mesurer les temps d’accès justement. Et du code pour remplir tout le cache ET du code pour le lire en entier.
    L'ensemble doit être possible à détecter ...
    Le code qui remplit le cache et le lit en entier, c'est une boucle for qui lit une colonne dans une matrice. On ne va pas pouvoir interdire tous les parcours de tableaux. On pourrait éventuellement interdire tous les timers, mais comme dit plus haut ça ne suffirait pas.

    Pour vraiment se prémunir des fuites d'info par le timing, il faut se limiter aux programmes dont le comportement est entièrement spécifié. C'est possible pour du code séquentiel, sans I/O. Mais les programmes de la vraie vie ont une fâcheuse tendance à vouloir interagir avec le monde extérieur.

    Par ailleurs, il faut aussi que les mecs aient accès à une appli largement distribuée de façon légitime. C'est surement le plus dure ...
    Javascript.

  22. #22
    J'avais pas pensé à Javascript en effet...
    Un ptit no-script va donc devenir obligatoire...

  23. #23
    Au dela du "on peut pas remonter le temps dans un superscalaire multicoeur", qui est une faille non-patchable a ce jour, y'a quand même un truc que je comprend pas pour spectre/meltdown: pourquoi le code spéculatif est exécuté en mode kernel ?
    tu fais un accès mémoire, et spéculation ou pas, tu devrai pas sortir de ce que te dit ta table de translation, nan ?
    La guerre, ce sont des idiots qui tapent sur des abrutis pour des raisons stupides.
    Citation Envoyé par Gwynyam Voir le message
    C'est pas du communautarisme primaire, mais plutôt un mal de front chronique dû aux facepalm incessants.

  24. #24
    De ce que j'avais compris ce n'est pas executé en mode kernel, c'est plutot que si tu a du code comme ceci :
    Autorisation d'accés en mode kernel
    -------------------
    Appel d'une partie en mode kernel
    -------------------

    Le code spéculatif entre le tirets ne sait pas si l'autorisation d’accès pour le kernel existe ou non. Il suppose alors que oui, et si il s'est trompé il n’exécutera simplement pas la partie et renverra une erreur de droit, j'imagine. Sauf qu'en attendant il l'a quand même executé ^^.

    Mais si c'est un code user dans la partie en question il sera surement executé en mode user j'imagine, sans plus de précision... je n'avais pas compris que l'execution spéculative était systématiquement en mode kernel.

  25. #25
    Au dela du "on peut pas remonter le temps dans un superscalaire multicoeur", qui est une faille non-patchable a ce jour, y'a quand même un truc que je comprend pas pour spectre/meltdown: pourquoi le code spéculatif est exécuté en mode kernel ?
    tu fais un accès mémoire, et spéculation ou pas, tu devrai pas sortir de ce que te dit ta table de translation, nan ?
    A priori c'est plutôt de Meltdown que tu parles. Dans tous les cas, plus facile à dire qu'à faire, probablement. Enfin, il y a plusieurs possibilités...

    1. Intel (et les autres*) n'ont pas du tout pensé à ce cas et alors d'un point de vue architectural, c'est pas déconnant de laisser les instructions qui dépendent d'un load qui fait une faute de permission s'exécuter, puisque ça évite d'ajouter du hard pour gérer ce cas particulier dans le pipe, et de toute façon, tout ce qui est illégal se fait jeter du pipeline quand le load avec la faute devient visible par le software (commit).
    2. Intel (et les autres) ont vu le coup mais ont pensé que ça serait inexploitable et n'ont donc pas voulu investir le hardware pour fermer le side-channel.


    En effet, il faut bien voir que sur la majorité des archi haute performances, le premier load (celui qui accède à une adresse kernel sans avoir le droit) part vert le pipeline qui exécute les loads, puis les instructions qui en dépendent partent vers leurs pipelines d'exécutions respectifs avant de savoir si le premier load est légal ou non. Du coup, pour fermer le side channel, il faut du hard pour "annuler" l'exécution des instructions dépendantes (ça c'est chaud je pense), ou pour rendre l'exécution inoffensive : par exemple, si le load est illégal, il renvoie 0 au lieu de renvoyer la valeur lue dans le cache (ça c'est plus facile, c'est peut-être ce que fait AMD par exemple). Cependant, même la dernière technique rajoute un multiplexeur dans le chemin critique du bypass ("si légal alors valeur du cache sinon 0"), et peut donc diminuer la fréquence maximale atteignable par le CPU si le bypass est le chemin critique du CPU. Et du coup le marketing n'est pas content.

    De ce que j'avais compris ce n'est pas executé en mode kernel, c'est plutot que si tu a du code comme ceci :
    Autorisation d'accés en mode kernel
    -------------------
    Appel d'une partie en mode kernel
    -------------------

    Le code spéculatif entre le tirets ne sait pas si l'autorisation d’accès pour le kernel existe ou non. Il suppose alors que oui, et si il s'est trompé il n’exécutera simplement pas la partie et renverra une erreur de droit, j'imagine. Sauf qu'en attendant il l'a quand même executé ^^.

    Mais si c'est un code user dans la partie en question il sera surement executé en mode user j'imagine, sans plus de précision... je n'avais pas compris que l'execution spéculative était systématiquement en mode kernel.
    Alors en effet l'exécution spéculative n'a pas systématiquement les permissions du kernel, elle a les permissions du contexte courant. Pour Meltdown, du code user fait un accès à une adresse privilégiée et prendra une faute de permission, mais aura exécuté "au delà" de la faute (chez Intel et d'autres). Notons que l'exécution spéculative n'a pas d'impact sur ce qui est visible pour le programmeur (l'état architectural), mais elle a un impact sur le cache notamment, d'ou le side channel en timant les accès mémoire après avoir déclenché la faute.

    *Parce que bon, tout le monde râle sur Intel pour Meltdown mais des CPUs d'IBM, Sun et ARM sont vulnérables aussi, il me semble.
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

  26. #26
    Citation Envoyé par Møgluglu Voir le message
    Javascript.
    Citation Envoyé par Nilsou Voir le message
    J'avais pas pensé à Javascript en effet...
    C'est cool, j'ai toujours dit que le développement web, c'est moche, sale et indigne - sans vraiment pouvoir le justifier en dehors de ma haine personnelle envers cette discipline. Au moins, je pourrais dorénavant sortir cet argument infaillible.

    Citation Envoyé par Thamior Voir le message
    Parce que bon, tout le monde râle sur Intel pour Meltdown mais des CPUs d'IBM, Sun et ARM sont vulnérables aussi, il me semble.
    A priori ça concerne énormément de processeurs OOO (out of order), et ça tombe mal, quasiment tous les procos modernes sont basés sur ce modèle.
    Même si certains font les innocents, tout le monde à l'air un peu touché, même si manifestement Intel est quand même bien plus concerné qu'AMD par exemple.


    Sinon je suis d'accord avec ce qui a été dit plus haut. Peut-être serait-il temps pour les responsables des architectures actuelles de faire un peu plus attention à la sécurité des données, sans pour autant abandonner complètement les critères de performances et de consommation bien sûr ; il y a sûrement un équilibre à trouver.

    Non parce que sinon, y'en a des moyens de gagner en perfs hein suffit par exemple de ne plus avoir aucune isolation kernel/user, aucune protection de la mémoire, aucune notion de privilèges...
    Tout ça, ça en ferait des "if" en moins. Et donc, des potentielles ruptures de séquence en moins.
    Bon, z'allez me dire, chez Intel on s'en fout des ruptures de séquence, on exécute le code avant, on réfléchit après
    Sombrero d'or since 2015/12/03
    Citation Envoyé par Darkath Voir le message
    Mais enfin c'est toi l'expert, trouve des solutions bordel.

  27. #27
    Haha,
    Bon en parlant du loups, j’installe des mises à jours bios et software sur mon pc, et pouf, qu'est-ce qui tombe, mise à jour Intel pour Meltdown et cie.
    J'imagine qu'ils ont patché deux trois trucs d'une façon quelconque pour réduire les risques.

    Alors je ne sais pas si c'est psychologique ou non (ou si c'est lié ou non) mais j'ai clairement l'impression de sentir des latences qu'il n'y avais pas auparavant ...

    - - - Mise à jour - - -

    Citation Envoyé par taronyu26 Voir le message
    C'est cool, j'ai toujours dit que le développement web, c'est moche, sale et indigne - sans vraiment pouvoir le justifier en dehors de ma haine personnelle envers cette discipline. Au moins, je pourrais dorénavant sortir cet argument infaillible.
    Après tout ce qui est à base d'autogestion de mémoire c'est du caca. Faudra que je retrouve le papier qui avait prouvé qu'aucun ramasse miette ne pourrais jamais être théoriquement infaillible...

  28. #28
    Non mais sinon pour Spectre c'est facile, le mov x86 est turing complet donc il suffit de faire ça : https://github.com/xoreaxeaxeax/movfuscator/tree/master/validation/doom
    No branch, no problem.
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

  29. #29
    Citation Envoyé par taronyu26 Voir le message
    Sinon je suis d'accord avec ce qui a été dit plus haut. Peut-être serait-il temps pour les responsables des architectures actuelles de faire un peu plus attention à la sécurité des données, sans pour autant abandonner complètement les critères de performances et de consommation bien sûr ; il y a sûrement un équilibre à trouver.
    Début 1990, DEC avait identifié un certain nombre de vulnérabilités par timing channels sur la microarchitecture du VAX, et ils avaient proposé des techniques de mitigation pour respecter les normes de sécurité en vigueur à l'époque. Par exemple le bruitage des timers explicites et implicites (timing des I/O) : https://content.iospress.com/article...ty/jcs1-3-4-04
    En 2016, après la publication des attaques rowhammer depuis Javascript, les principaux browsers web ont commencer à (mal) appliquer ce type de technique pour certains timers explicites.

    Il aura juste fallu attendre 30 ans que la mode du PC passe.

    Citation Envoyé par Nilsou Voir le message
    Haha,
    Bon en parlant du loups, j’installe des mises à jours bios et software sur mon pc, et pouf, qu'est-ce qui tombe, mise à jour Intel pour Meltdown et cie.
    J'imagine qu'ils ont patché deux trois trucs d'une façon quelconque pour réduire les risques.

    Alors je ne sais pas si c'est psychologique ou non (ou si c'est lié ou non) mais j'ai clairement l'impression de sentir des latences qu'il n'y avais pas auparavant ...
    Ça encore ça va, si tu n'observes pas plus de reboots qu'avant tu t'en sors bien. Entre temps Intel a fait machine arrière et recommande de ne pas faire la mise à jour du microcode :
    https://newsroom.intel.com/news/root...-and-partners/

  30. #30
    J'ai pas trop compris cette histoire de "mode" du PC.
    Sombrero d'or since 2015/12/03
    Citation Envoyé par Darkath Voir le message
    Mais enfin c'est toi l'expert, trouve des solutions bordel.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •