Journal Toi aussi, amuses toi avec le FireWire

Posté par . Licence CC by-sa
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 (page perso) . É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 (page perso) . É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/01/14 à 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 (page perso) . É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 (page perso) . É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/01/14 à 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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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.

          • [^] # 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.

              • [^] # 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.

    GRUB3 will be Elisp serialized as XML jited to JVM running as Eclipse plugin on a Mac running in a virtual PC in a Xen instance on a 286er.

Suivre le flux des commentaires

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