Vulnérabilité dans le protocole Firewire

Date : 02 Avril 2008

Une vulnérabilité évoquée en 2004, puis longuement exposée en 2005 et 2006 ressurgit début mars 2008. Pourquoi celle-ci attire t'elle de nouveau l'attention ? Adam Boileau, l'auteur de la dernière publication, avance que celle-ci est motivée par l'absence de reconnaissance du problème par Microsoft.

Pourquoi celle-ci s'est faite oublier ? Peut-être parce qu'il y à 2 ans le Firewire faisait peut d'émules, hormis les amateurs de montages vidéos, nécessitant les débits apportés par cette technologie. Peut-être aussi parce que l'exploitation de cette "vulnérabilité" nécessite un accès physique à une machine vulnérable pour être exploitée. Par conséquent d'autres vulnérabilités lui sont préférées.

Sans épiloguer sur les raisons de ce léger "oubli", pourquoi cette technologie attire t'elle à nouveau l'attention ?


Un peu d'histoire

Inventé dans les années 1990 par Apple, Texas-Instrument et Sony, puis normalisé en 1995, le Firewire a été initialement conçu pour concurrencer (à l'époque) l'USB. Appelé "i.LINK" chez Sony, mais plus généralement connu sous son nom "IEEE 1394", le Firewire est une interface série de type "plug and play", permettant des transferts de données isochrones c'est-à-dire rapides et réguliers. Il offre un bus de communication multiplexé rapide, et permet de connecter à chaud toutes sortes de périphériques (jusqu'à 63). Ces derniers sont principalement de gros consommateurs de bande passante (caméscopes numériques, appareils photos, disques durs amovibles, etc.).

Le modèle de communication du Firewire est basé sur le "peer-to-peer". Chaque périphérique peut directement dialoguer avec un autre sans passer par le contrôleur. Une même information peut donc être envoyée directement vers plusieurs périphériques simultanément.

Nous passerons sur les détails techniques de cette norme, puisque ce n'est pas l'objet du présent article, sachez tout de même que plusieurs versions existent, et que leurs débits vont de 100Mb/s à plus de 400Mb/s pour la version 1, et de 800Mb/s à 3200Mb/s pour la version 2.


Vulnérabilité ou erreur de conception ? 

Le problème de sécurité qui est induit par cette norme est le fait qu'un périphérique branché sur le port Firewire d'un ordinateur peut utiliser cette interface pour accéder en lecture et écriture à certaines zones de la mémoire centrale de l'ordinateur. Ce type d'attaque a été évoqué depuis longtemps. En 2004, Maximilian Dornseif écrit un programme permettant d'attaquer un système doté d'un port Firewire via un iPod (cf. l'article "Owned by an ipod"). En 2005, il formalise ses découvertes dans une présentation "FireWire : all your memory are belong to us" lors de la conférence CanSecWest.

En 2006, lors d'une conférence Ruxcon à Sydney, Adam Boileau décortique dans son exposé "Hit By A Bus: Physical Access Attacks with Firewire" le fonctionnement des accès physiques à la mémoire via le Firewire. Dans sa présentation, il met l'accent sur les interactions des accès aux données stockées en mémoire par le contrôleur DMA (Direct Memory Access) d'un système hôte accueillant ce type de périphérique. La technique consiste à exploiter les fonctions mêmes du protocole pour accéder en lecture et en écriture à toute la mémoire adressable par le système. Pour gagner en rapidité, le protocole s'affranchit d'intermédiaires (processeur, contrôleurs, systèmes d'exploitation, etc.). Afin de diminuer les temps de latence d'accès aux données, le protocole Firewire manipule directement le contrôleur DMA physique de la machine. Le gain de rapidité se fait au détriment de tout contrôle d'accès aux données. La mémoire est alors entièrement accessible.

Techniquement l'allocation des droits d'accès au contrôleur DMA, se fait par une simple requête d'un périphérique au système d'exploitation à travers deux registres appelés CSR (Config Status Register).

Il s'agit donc d'une faiblesse inhérente au protocole Firewire, et non d'une vulnérabilité d'implémentation.


Exploitation/Attaque

Plusieurs techniques existent. La première consiste à brancher directement un portable sous Linux sur la connexion Firewire d'un système vulnérable. Le lancement d'une distribution spécifique exploitant la librairie "libraw1934" permet de simuler le montage d'un dispositif Firewire au système hôte et d'en lire sa mémoire. Le système vulnérable n'a aucune notion des accès qui sont faits à sa mémoire système. La distribution permet ensuite la recherche des données d'authentification du système, puis leur modification. C'est notamment le programme "winloclpwn" qui a relancé la polémique. En effet ce programme de démonstration du Ruxcon de Sydney est revenu sur le devant de la scène en mars dernier. Il permet de contourner l'authentification d'une session Windows verrouillée, ou de lancer un shell avec les privilèges d'administration, en connectant simplement un périphérique Firewire à un système Windows XP vulnérable. Il est à noter que l'on croyait Windows Vista prémuni contre ce type d'attaque, mais il semblerait que le code d'Adam Boileau ait été porté pour fonctionner sur ce dernier.

D'autres programmes ou distributions Linux utilisent des techniques similaires et permettent entre-autres ; la modification directe du mot de passe d'administration des systèmes Windows, l'exécution de codes malveillants, le contournement des contrôles d'accès, la récupération de mots de passe, de clés privées, qu'il est ensuite aisé d'attaquer par "brute force".

Adam Boileau, décrit également les nombreuses possibilités d'exploitation de cette vulnérabilité, citons parmi celles-ci ; l'implémentation de keylogger, la modification de la mémoire vidéo, l'injection de DLL, l'installation de rootkits, etc.


D'autres utilisations

Au-delà de l'exploitation de cette technique à des fins malveillantes, elle peut être également utilisée à d'autres fins telles que le débogage d'applications, de pilotes de périphériques (drivers), l'analyse "forensic" de la mémoire, l'analyse de l'exécution en mémoire de malware, voire même la récupération de pages écrans stockées en mémoire vidéo d'un système (duplication vidéo).


Difficultés

Toutefois, il n'est pas nécessaire de s'alarmer, les nombreux outils existant sont peu évolués. Les techniques de reconnaissance ou de reconstruction restent souvent immatures, et nécessitent des temps de calcul et d'analyse très longs.

Ceci s'explique par la structure virtualisée de l'espace d'adressage de la mémoire, dans laquelle les pages mémoires de 4 kilo-octets seulement ne sont accessibles qu'après plusieurs indirections de pointeurs. La mémoire est très volatile, change et évolue rapidement et se fragmente très vite. Tout ceci rend difficile la tâche de reconstruction.

Les programmes exploitant quant à eux les contournements d'authentification, doivent rechercher les structures systèmes, les librairies dynamiques au sein même de la mémoire afin de reconstruire les structures d'appels de fonctions, et plus généralement les structures de données (ex. MsGina.DLL, etc.).


D'autres systèmes sont ils vulnérables ?

Les systèmes Windows sont "vulnérables", mais d'autres systèmes le sont également. En effet, la "vulnérabilité" porte sur la conception de cette norme, qui n'interdit pas les lectures/écritures directes dans la mémoire du système hôte. A ce titre, les systèmes tels que Linux ou Macintosh OS X sont tout aussi vulnérables que les systèmes Windows. D'ailleurs l'un des premiers "proof-of-concept" de Maximilian Dornseif, s'attaquait via un iPod aux systèmes Linux et non Windows.

Et l'USB ?

Il est légitime de se poser la question, si le concurrent de la technologie Firewire, l'USB, présente les mêmes faiblesses que son homologue. Apparemment ce n'est pas le cas. La norme du protocole USB n'autorise pas les accès directes à la mémoire, en tout cas pas directement depuis les périphériques USB. Le système d'exploitation et le processeur gèrent toutes les autorisations d'accès à la mémoire. L'exploitation des accès directs en lecture ou en écriture semble donc impossible.


Comment s'en protéger ?
 
La norme utilisant le Firewire et notamment son interface système (OHCI-1394 – Open Host Controller Interface) offre peu de possibilités pour réduire le risque d'attaque par Firewire. La raison est simple, et nous l'avons évoqué, cette vulnérabilité n'en est pas vraiment une, mais plutôt un défaut de conception. La norme a autorisé le Firewire à accéder directement à la mémoire, c'est ceci qui est exploité.

S'il est difficile de protéger physiquement les ports Firewire, leur désactivation via le BIOS reste à la portée de tout le monde. Certains systèmes, c'est le cas du Macintosh G5, offrent la possibilité de mettre en œuvre une protection par mot de passe lors de l'accès à ces ports. Cette technique reste toutefois marginale.

Précedent Précedent Suivant Suivant Imprimer Imprimer