Journal Toi aussi, amuses toi avec le FireWire

PostĂ© par . Licence CC By‐SA.
Étiquettes :
44
26
jan.
2014

Bonjour Nal,

Les problĂšmes liĂ©s au FireWire sont connus et identifiĂ©s depuis longtemps. Voir par exemple cet excellent papier datant de 2008, de Uwe Hermann, dĂ©veloppeur Debian, Ă  ce sujet. En gros, Ă  partir du moment oĂč tu as un accĂšs physique Ă  la machine, tu peux :

  • lire et Ă©crire arbitrairement dans la RAM ;
  • Avoir accĂšs Ă  un disque chiffrĂ© sans en connaĂźtre la clef ;
  • ... et plein de trucs visiblement trĂšs rigolos

Alors, chez Nal, pourquoi je viens t'embĂȘter Ă  parler de cette vieillerie ? Parcequ'un outil rend tout cela Ă  jour (pour ĂȘtre utilisĂ© contre des systĂšme modernes comme Linux 3 et OSX et Windows 7 ou 8): c'est Inception (licence gpl v3), qui utilise la libforensic (disponible dans ta distribution, licence Lgpl). Relie ton portable Ă  celui de ta cible par un cable Firewire, et voilĂ . MĂȘme si le disque est chiffrĂ©, tu va avoir accĂšs Ă  tout... Pour Windows, celui ci semble limiter l'usage du dma depuis longtemps, mais ne semble toujours pas enclin Ă  laisser les gens dĂ©cider par eux-mĂȘmes, il suffit donc de faire passer son matĂ©riel pour un "ipod" (ou tout autre gadget Ă lacon) pour pouvoir exploiter cette faille. Pour MacOSX, il semble que sa pile firewire soit tellement bugguĂ©e que le noyau panique parfois lors de l'usage d'inception (et il intĂšgre l'arrĂȘt du dma dĂšs que la machine est verrouillĂ©e). Quant Ă  linux... tu ferais quoi, cher Nal ?

inception

En fait, PCMCIA, ExpressCard, Thunderbold, tout ces jolis joujous rendent nos machines vulnĂ©rables. Peut ĂȘtre d'autres encore ? Lesquels ?

Plus d'informations générales sur le site de Damien Douxchamps, auteur de la libdc1394 (bibliothÚque permettant le contrÎle des caméras utilisant IEE1394) et sur le wiki iee1394 du site de notre noyau

  • # Punaise

    PostĂ© par (site web personnel) . ÉvaluĂ© Ă  10.

    Punaise, tu veux dire que le trou est béant depuis 2008 ?

    • [^] # Re: Punaise

      PostĂ© par . ÉvaluĂ© Ă  10.

      Depuis que Apple a inventé cette merveille, donc ~1994
      \o/

    • [^] # Re: Punaise

      PostĂ© par (site web personnel) . ÉvaluĂ© Ă  2.

      Non, je crois qu'Apple désactive le transfert en DMA quand tu utilises filevault.

      Et j'ai tentĂ© de trouver les cables kivonbien mais sans grand succĂšs pour vĂ©rifier, ça a l'air d'ĂȘtre le merdier.

      • [^] # Re: Punaise

        PostĂ© par . ÉvaluĂ© Ă  4. DerniĂšre modification le 26 janvier 2014 Ă  17:02.

        Oui, c'est pourquoi les auteurs utilisent Inception sur Thunderbold / DisplayPort, mais lorsque l'usager est loggué. Afin de dumper la ram, puis d'en extraire le mot de passe de FileVault2 (c'est étrange qu'il n'y pas une option du style auth-nocache pour filevault et bitlocker) Bon, la vidéo a été supprimée de Youtube mais il reste l'article qui a deux ans.

        moi ça m'espante
        et je vais de ce pas acheter un adaptateur pour mon Acer ...

        • [^] # Re: Punaise

          PostĂ© par . ÉvaluĂ© Ă  2.

          les auteurs utilisent Inception sur Thunderbold / DisplayPort

          Thunderbolt, c'est DisplayPort + PCI express et c'est le bus PCI express qui est utilisé par cette "feature", c'est bien ça ? Et donc DisplayPort n'a rien à voir là dedans (il est quasiment à sens unique), je suppose ?

        • [^] # Re: Punaise

          PostĂ© par . ÉvaluĂ© Ă  4.

          (c'est Ă©trange qu'il n'y pas une option du style auth-nocache pour filevault et bitlocker

          filevault c'est du chiffrement soft, donc la clef a besoin d'ĂȘtre en ram pour n'importe quelle opĂ©ration sur le filesystem, du coup je ne vois de quelle option tu pourrais parler ...

          • [^] # Re: Punaise

            PostĂ© par (site web personnel) . ÉvaluĂ© Ă  2.

            On peut imaginer que la clé soit stocké chiffré en ram, et qu'il faille utiliser le mot de passe de l'user pour la déchiffrer, ou ce genre de choses. Ou que le matos apple dépende d'une puce TPM ou autre non accessible directement et pas en ram.

            • [^] # Re: Punaise

              PostĂ© par . ÉvaluĂ© Ă  3.

              Mais non !
              L'important, ici c'est que tu as besoin de la clef en clair en mémoire pour chaque opération sur un fichier, c'est à dire en permanence. Tu ne peux pas demander le mdp à l'utilisateur en permanence à chaque accÚs fichier (filevault est un erzatz de FDE, pas de chiffement de quelques fichiers à droite à gauche, il chiffre toute une partition).

              Quant au TPM, ca ne pourrait pas marcher parce qu'un TPM c'est trÚs lent (vraiment trÚs trÚs lent), donc on ne pourrait pas lui sous traiter les opérations de chiffrement (et qui plus est, un TPM n'est pas vraiment fait pour faire de la crypto symétrique).

              • [^] # Re: Punaise

                PostĂ© par . ÉvaluĂ© Ă  2.

                Et quand bien mĂȘme, on aurait toujours le problĂšme de l'accĂšs en Ă©criture. Ça veut dire qu'on peut modifier la fonction de dĂ©chiffrement pour qu'elle exhibe la clef.

                Please do not feed the trolls

  • # faut relativiser

    PostĂ© par . ÉvaluĂ© Ă  1.

    sur certaines de mes machines recentes libdc1394 n'est meme pas installé

    • [^] # Re: faut relativiser

      PostĂ© par (site web personnel) . ÉvaluĂ© Ă  3.

      Sur une Debian sid, si j'essaye de virer la libdc1394-22, je perds cheese, gnome-video-effects, pidgin (et donc telepathy-haze), ainsi que vlc.

      Donc mĂȘme si pour ma part je ne me serts pas du Firewire, il ne me semble pas simple de virer ce genre de «faille».

      alf.life

    • [^] # Re: faut relativiser

      PostĂ© par . ÉvaluĂ© Ă  10. DerniĂšre modification le 26 janvier 2014 Ă  15:20.

      Cette bibliothÚque n'est pas en cause, elle n'est mentionnée que pour ceux souhaitant lire plus, son site étant particuliÚrement fourni en informations lisibles par tous. C'est la gestion du DMA par l'IEE1394 qui est en cause, donc directement la norme...

      Sous les Linux anciens, utilisant encore ohci1394, il suffit de passer une option au chargement du module : phys_dma=0 afin de dĂ©sactiver cela. Sur les Linux plus rĂ©cents, c'est la nouvelle pile "juju" qui s'occupe de l'IEE1394, et ses diffĂ©rents modules n'ont visiblement pas repris cette option [ need info ] Il y en a mĂȘme deux qui sont spĂ©cifiquement dĂ©diĂ©s au debug (au lieu d'avoir seulement une option debug), sur le noyau Fedora ces deux modules ne sont pas compilĂ©s. Mais blacklister firewire_core semble ĂȘtre de toutes façons la solution la plus simple. Plus d'intrusion possible par ces voies lĂ , paf la faille.

      Non ?

  • # Sata 3.2

    PostĂ© par (site web personnel) . ÉvaluĂ© Ă  10.

    C'Ă©tait effectivement connu depuis longtemps pour le firewire. Qu'en est il du sata 3.2 qui expose le bus pci express ? En y connaissant rien, on peut supposer que les mĂȘme failles existent non ?

    • [^] # Re: Sata 3.2

      PostĂ© par . ÉvaluĂ© Ă  1.

      J'aurais tendance à dire que si le device se connecte au bus PCI Express, il peut faire du bus mastering et accéder à potentiellement tout ce qu'il veut.
      Cela dit, on peut protéger avec un IOMMU, en ne donnant accÚs qu'à des plages d'adresses bien spécifiques.

      • [^] # Re: Sata 3.2

        PostĂ© par . ÉvaluĂ© Ă  2.

        Ouais mais les IOMMU, y a personne qui s'en sert Ă  part les hyperviseurs :/

  • # IntĂ©rĂȘt du FireWire ?

    PostĂ© par (site web personnel) . ÉvaluĂ© Ă  5.

    Je trouve qu'il y a encore pas mal de pĂ©riphĂ©riques ou ordinateurs qui ont un port FireWire. Quel est l'intĂ©rĂȘt de cette connectique ?
    Car quand on regarde, l'USB est bien plus universel encore et offre des débits similaires voire supérieure suivant la version de la norme.

    Tous les avantages de cette connectique lors de sa création comme le branchement à chaud, ont été mise en place également dans l'USB, le SATA et d'autres. Donc pourquoi garder cette vieillerie ?

    • [^] # Re: IntĂ©rĂȘt du FireWire ?

      PostĂ© par (Mastodon) . ÉvaluĂ© Ă  9.

      L'USB n'a pas tous les avantages du FireWire. Par exemple on ne peut pas faire ce qui est décrit dans ce journal.

      Plus sérieusement, oui, l'USB offre tout ce que le FireWire fait, maintenant. Sauf utiliser les périphériques FireWire existant (il doit bien en rester...)

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: IntĂ©rĂȘt du FireWire ?

        PostĂ© par . ÉvaluĂ© Ă  8.

        L'USB n'a pas tous les avantages du FireWire. Par exemple on ne peut pas faire ce qui est décrit dans ce journal.

        Peut-ĂȘtre mĂȘme que le FireWire a Ă©tĂ© poussĂ© par la NSA...

        Article Quarante-Deux : Toute personne dĂ©passant un kilomĂštre de haut doit quitter le Tribunal. -- Le Roi de CƓur

    • [^] # Re: IntĂ©rĂȘt du FireWire ?

      PostĂ© par . ÉvaluĂ© Ă  2.

      Le FireWire est multimaĂźtre, au contraire de l'USB.

    • [^] # Re: IntĂ©rĂȘt du FireWire ?

      PostĂ© par . ÉvaluĂ© Ă  3.

      il me semble avoir lu que le FireWire dispose de latences beaucoup moins importantes que l'USB, ce qui est apprĂ©ciable / indispensable dans certains secteurs d’activitĂ©, comme l'audio pro.

      • [^] # Re: IntĂ©rĂȘt du FireWire ?

        PostĂ© par . ÉvaluĂ© Ă  5.

        Exact, les cartes son pro utilisent FireWire, comme le recommande l'auteur d'Ardour : pas de bruits parasites contrairement Ă  l'audio interne, et latence aussi faible.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: IntĂ©rĂȘt du FireWire ?

          PostĂ© par . ÉvaluĂ© Ă  3.

          Je pense qu'il comparait le fait d'avoir une carte son Firewire ou USB de gamme supérieures à ce qui se fait en matiÚre de carte son PC pour madame Michu.

          L'avantage en Firewire est d'avoir un flux de donnĂ©es constant au fil de l'utilisation, en utilisant la bande passante nĂ©cessaire Ă  l'envoi de donnĂ©es, contrairement Ă  l'usb oĂč les donnĂ©es sont envoyĂ©es quand il y en a, en utilisant un maximum de bande passante.

          Maintenant dire si l'intĂ©rĂȘt est toujours autant en faveur du Firewire est toujours aussi grand je ne sais pas.

          J'aurais tendance Ă  dire qu'il y a toujours un point en sa faveur : le protocole est fait pour traiter un flux constant, ce qui n'est pas le cas de celui de l'usb.

          On peut donc plus difficilement prévoir la quantité de données à traiter ce qui est crucial en enregistrement audio. En cas de dépassement de la taille de la mémoire tampon (qu'on essaie de garder le plus petit possible pour éviter la latence), on se retrouve avec un trou dans l'onde qui oblige à reprendre la prise...

          Ceci dit je ne suis pas un expert, et suis preneur d'avis éclairés en la matiÚre. Sa main ThérÚse.

          Merci de prendre le commentaire ci-dessus avec: un peu de recul, le premier degré, et si possible le second !

          • [^] # Re: IntĂ©rĂȘt du FireWire ?

            PostĂ© par . ÉvaluĂ© Ă  2.

            L'avantage en Firewire est d'avoir un flux de donnĂ©es constant au fil de l'utilisation, en utilisant la bande passante nĂ©cessaire Ă  l'envoi de donnĂ©es, contrairement Ă  l'usb oĂč les donnĂ©es sont envoyĂ©es quand il y en a, en utilisant un maximum de bande passante.

            L'USB possĂšde aussi un mode de transfert de type isochrone.

            • [^] # Re: IntĂ©rĂȘt du FireWire ?

              PostĂ© par . ÉvaluĂ© Ă  2.

              En effet, je connaissais pas.

              Par contre lors d'aprĂšs mes courtes recherches, il semblerait que l'usb fonctionne par packets en half duplex et le firewire par stream donc en full duplex. Donc Ă  l'avantage du Firewire.

              Merci de prendre le commentaire ci-dessus avec: un peu de recul, le premier degré, et si possible le second !

              • [^] # Re: IntĂ©rĂȘt du FireWire ?

                PostĂ© par . ÉvaluĂ© Ă  1.

                C'est vrai pour l'USB 1.1 et 2.0, qui ne disposent que d'une seule paire différentielle pour les données. L'USB 3.0 dispose de deux paires, il est apte au full-duplex.

  • # Faille inexistante sous Linux

    PostĂ© par . ÉvaluĂ© Ă  10.

    Quant Ă  linux...

    Linux est trÚs bien sécurisé, contrairement à ce qui est suggéré dans le journal. Personnellement, je n'ai jamais réussi à faire fonctionner le firewire :-)

  • # IPMI

    PostĂ© par . ÉvaluĂ© Ă  1.

    En fait, PCMCIA, ExpressCard, Thunderbold, tout ces jolis joujous rendent nos machines vulnĂ©rables. Peut ĂȘtre d'autres encore ? Lesquels ?

    Je parie un paquet de cacahuĂštes sur IPMI, mais c'est peut-ĂȘtre un peu trop facile.

    a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence

Suivre le flux des commentaires

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