Journal Des firmwares, des backdoors et du libre

Posté par  (site web personnel) .
22
8
août
2012

Certains d'entre vous ont sans doute entendu parler ou vue la présentation de Rakshasa, c'est la POC d'une superbe backdoor qui fait froid dans le dos : cela permettrais d'infecter les bios de cartes mères, de cartes réseaux, en gros pas mal de composants ayant un firmware non libre (ou ayant un firmware libre, mais dans ce cas nous pourrions le recompiler et le reflasher).
C'est développé avec du libre (coreboot, SeaBIOS, iPXE…) mais ne cherchez pas les sources, ce n'est pas disponible.

D'ailleurs, en parlant de firmware libre, un développeur de chez Google développe un remplaçant au blob binaire du bios vidéo des processeurs Ivy-Bridge de leurs Chromebook.
Ce remplaçant est basé sur coreboot.

Ahhh je rêve toujours d'un matériel 100% libre !

PS : Le drivers libre freedreno dont j'avais parlé ici poursuit son petit bonhomme de chemin avec un début de gestion des textures

  • # Un détail

    Posté par  . Évalué à 5.

    Il m'a l'air bien gentil ce petit, mais il oublie un détail: Sur ma machine, il y a un jumper qui verrouille la possibilité de flasher le BIOS.

    Sur les laptops ce n'est peut être pas le cas, mais je trouve qu'il va un peu vite en besogne lorsqu'il affirme "Il n'y aura pas de patch, c'est la faute de l'architecture, il faudrait tout changer pour réparer".

    Un simple cavalier et le tour est joué.

    • [^] # Re: Un détail

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 09 août 2012 à 09:52.

      Avant, ce genre de cavalier était branché sur le hardware de la puce de mémoire flash pour directement empêcher l'écriture. Aujourd'hui, je ne serais pas étonné que cela soit simplement un IO dont l'état haut ou bas est vérifié par du code très bas niveau. Cela veut dire que si une faille logiciel existe, un tel cavalier peut être contourné.

      Cela fait beaucoup de "si", je suis d'accord.

      "La première sécurité est la liberté"

      • [^] # Re: Un détail

        Posté par  . Évalué à 2.

        Aujourd'hui, je ne serais pas étonné que cela soit simplement un IO dont l'état haut ou bas est vérifié par du code très bas niveau.

        Ca m'étonnerais: Si c'est un "switch" logiciel, ca devient complètement inutile. De mémoire, le but de ce cavalier était à la fois d'empêcher les erreurs de l'utilisateur et de protéger la machine contre - justement - du code malveillant.

        Cela veut dire que si une faille logiciel existe, un tel cavalier peut être contourné.

        Tout à fait, en admettant que tu aies raison, ce que le code fait, le code peut le défaire. Mais comme je te disais, je pense qu'il y a soit le jumper, soit rien du tout.

        Mais dans tout les cas ca porte un sacré coup à son affirmation "Mouaaa il faut revoir toute l'archi x86 pour fixer la faille que j'exploite". Il suffit de revenir au jumper.

        En plus, il y a un fix très simple: Tu prends ta puce, tu coupes la patte "Vpp" et problème réglé.

        • [^] # Re: Un détail

          Posté par  (site web personnel) . Évalué à 2.

          Cela fait longtemps qu'il n'y a plus de pattes Vpp sur une mémoire flash. Déjà en 2000, les pompes de charges pour créer du 12V était internet à la puce.

          "La première sécurité est la liberté"

          • [^] # Re: Un détail

            Posté par  . Évalué à 10. Dernière modification le 09 août 2012 à 11:31.

            Cela fait longtemps qu'il n'y a plus de pattes Vpp sur une mémoire flash. Déjà en 2000, les pompes de charges pour créer du 12V était internet à la puce.

            C'est une techno spécifique aux Pentium non ? ;)

      • [^] # Re: Un détail

        Posté par  . Évalué à 5.

        J'ai l'impression que vous avez un peu loupé le l'idée du papier.
        L'idée c'est que si le fabriquant ( la chine ) décide de mettre se genre de backdoor dans le matériel on n'a "aucun moyen" de contourner le problème. Et on s'en rendra compte quand ce sera trop tard.

        C'est aussi valable si il y a un seul employé du fabriquant qui décide de jouer au plus malin et ça c'est déjà produit. Je me rappelle d'une histoire d'en le genre un lecteur mp3 qui était fourni par l'usine avec un firmware qui infectait la machine.

        • [^] # Re: Un détail

          Posté par  . Évalué à 5. Dernière modification le 09 août 2012 à 10:16.

          De plus l'infection n'a pas besoin de se propager par le BIOS : elle peut le faire sur tous les périphériques PCI.

          Par exemple, acheter une carte graphique corrompue, qui ira compromettre la carte réseau ou un contrôleur disque PCI. Tout ce qui transite sur le bus PCI pourra alors facilement et silencieusement être exfiltré sur le réseau, indépendamment de toute corruption du BIOS.

          De plus pour peu que la carte réseau dispose d'une interface d'administration à distance de la machine…

        • [^] # Re: Un détail

          Posté par  . Évalué à 5.

          L'idée c'est que si le fabriquant ( la chine ) décide de mettre se genre de backdoor dans le matériel on n'a "aucun moyen" de contourner le problème

          Ben je ne vois pas ce que ça a nouveau. Les fabricants peuvent déjà mettre des backdoors matériels sur n'importe quoi (clavier, carte réseau, bios, etc) sans qu'on puisse passer outre.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Un détail

            Posté par  (site web personnel) . Évalué à 2.

            Il existe même une BD en ligne sur ce sujet, mais impossible de remettre la main dessus. Elle avait un style graphique particuliers, assez riche, genre une image 3D retravaillé à la main.

            "La première sécurité est la liberté"

            • [^] # Re: Un détail

              Posté par  . Évalué à 1.

              Je crois que je vois à quelle BD tu fais référence, un comics publié en 2005 par le site zone-h.org.

              Malheureusement, l'URL originale ne fonctionne plus.

              Heureusement, j'ai pu retrouver une copie du prologue (pas encore regardé si les épisodes suivants sont dispos) :
              http://it.scribd.com/doc/16663457/zoneh-comics-prologue

          • [^] # Re: Un détail

            Posté par  (site web personnel) . Évalué à 3.

            Les fabricants peuvent déjà mettre des backdoors matériels sur n'importe quoi

            Il y en a eue une il n'y a pas si longtemps sur des processeurs destinés à du matériel militaire. Il faudrait que je retrouve ma source..

    • [^] # Re: Un détail

      Posté par  (site web personnel) . Évalué à 2.

      Il y a surtout le détail idiot que toutes les cartes mère neuves n'ont plus de bios mais un UEFI.

      Donc sur un pc plutôt récent une attaque de bios est inutile.

      Sinon si on a pas de cavalier pour bloquer un écriture il y a aussi les cartes mère dual bios : si ton bios est corrompu, tu le réécris avec le bios d'à côté qui est bloqué en écriture.

      • [^] # Re: Un détail

        Posté par  . Évalué à 5.

        Donc sur un pc plutôt récent une attaque de bios est inutile.

        Ben, c'est là que EFI est bien fait : 99% des cartes graphiques actuelles n'ont pas de firmware EFI, mais ils faut bien les initialiser.

        EFI propose donc un mode Legacy, qui permet d'exécuter les Options Rom des périphériques compatibles bios uniquement.

        Mais à partir du moment où tu as EFI, c'est vrai qu'une attaque de bios est inutile : une attaque en mode EFI fait aussi l'affaire.

    • [^] # Re: Un détail

      Posté par  . Évalué à 2.

      Le jumper, c'est pas vraiment un problème : le code malicieux n'a pas besoin d'être flashé sur la carte mère.

      Pour peu que tu aies branché une carte graphique, un contrôleur de disques, ou une carte réseau équipée d'une rom PXE, elles peuvent en théorie accueillir son exploit (et c'est pas nouveau, ça a déjà été démontré).

      Et avec EFI, comme ça a déjà été démontré aussi, le code peut même simplement être présent sur le disque dur ou une une clé USB.

      Par contre, j'ai pas trouvé de vidéo de la démo (enfin, je suppose qu'il a au moins fait une démo lors de sa présentation), et j'ai quand même quelques doutes sur le côté furtif de la chose… sans parler de l'aspect technique de l'utilisation du wifi dans le bios pour récupérer le payload. Et la récupération du payload lors du boot, c'est quand même la nouveauté que propose sa présentation.

      Pour les laptops qui n'utilisent pas EFI, y'a pas de risque : ils ne sont pas supportés par coreboot.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.