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 ?
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 antistress (site web personnel) . Évalué à 10.
Punaise, tu veux dire que le trou est béant depuis 2008 ?
[^] # Re: Punaise
Posté par bubar🦥 (Mastodon) . Évalué à 10.
Depuis que Apple a inventé cette merveille, donc ~1994
\o/
[^] # Re: Punaise
Posté par diorcety . Évalué à 9.
BRRRRRRRAAAAAWWWWRWRRRMRMRMMRMRMMMMM
[^] # Re: Punaise
Posté par Anonyme . Évalué à 6.
Jerry Golay.
[^] # Re: Punaise
Posté par ariasuni . Évalué à 2.
Bonjour, je viens te remercier depuis le paradis de ma crise cardiaque.
Cordialement,
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Punaise
Posté par serianox . Évalué à 1.
Ça marchait aussi avant avec ExpressCard. :)
[^] # Re: Punaise
Posté par Misc (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 bubar🦥 (Mastodon) . É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 gnx . Évalué à 2.
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 oinkoink_daotter . Évalué à 4.
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 Misc (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 oinkoink_daotter . É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 Zylabon . É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 NeoX . Évalué à 1.
sur certaines de mes machines recentes libdc1394 n'est meme pas installé
[^] # Re: faut relativiser
Posté par Kioob (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 bubar🦥 (Mastodon) . É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 Gauthier Monserand (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 galactikboulay . É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 oinkoink_daotter . Évalué à 2.
Ouais mais les IOMMU, y a personne qui s'en sert à part les hyperviseurs :/
# Intérêt du FireWire ?
Posté par Renault (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 2PetitsVerres . É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 zebra3 . Évalué à 8.
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 gnx . Évalué à 2.
Le FireWire est multimaître, au contraire de l'USB.
[^] # Re: Intérêt du FireWire ?
Posté par Seb . É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 Elfir3 . É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 gnx . Évalué à 2.
L'USB possède aussi un mode de transfert de type isochrone.
[^] # Re: Intérêt du FireWire ?
Posté par Elfir3 . É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 gnx . É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 arnaudus . Évalué à 10.
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 Tsomi . Évalué à 1.
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.