Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Affichage des résultats 1 à 3 sur 3
  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.

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
  •