Des pare-feux pour le HDMI

Magazine
Marque
MISC
Numéro
127
Mois de parution
mai 2023
Spécialité(s)


Résumé

Le standard HDMI renferme un ensemble de fonctionnalités qui dépasse le simple transfert de signal vidéo. Ces fonctionnalités sous souvent inutilisées, mais présentent une surface d'attaque non négligeable. Cet article détaille la nature de ces fonctionnalités, puis propose des outils de filtrage pour protéger les périphériques HDMI.


Body

Quoi de plus banal qu'un câble vidéo. Dans une salle de réunion, le même projecteur ou écran est utilisé à tour de rôle pour projeter les présentations d'un visiteur, d'un employé, ou d'un conseil d'administration. Cette pratique est-elle saine, ou présente-t-elle un risque pour les ordinateurs qui viennent au contact du même moyen de projection ? En effet, si une vulnérabilité permet d'injecter un code malveillant dans une mémoire non volatile du moyen de projection, celui-ci pourrait à son tour infecter l'ordinateur qui y sera branché à la suite. Ce scénario de menace est illustré dans la figure 1.

menace-s

Fig. 1 : Scénario de menace.

La première partie de cet article détaillera les technologies mises en œuvre par le standard HDMI, afin de mieux comprendre les risques encourus. Dans la seconde partie, nous proposerons un prototype de dispositif matériel qui permet d'écarter ces risques, en bloquant les flux de données non essentiels et indésirables tout en laissant passer le signal vidéo. Plusieurs évolutions de ce prototype ont été réalisées afin de permettre plus de flexibilité et de faciliter l'étude des protocoles impliqués. Leur description sera l'objet de la troisième partie de cet article.

1. Les signaux véhiculés par le câble HDMI et leurs risques

Le standard HDMI (High-Definition Multimedia Interface) est spécifié depuis 2002 par le forum HDMI, composé d'un grand nombre de compagnies privées. L'objectif principal de ce standard est la transmission numérique de données vidéo et audio d'un équipement source (ordinateur, lecteur DVD...) vers un équipement dit puits (sink), qui peut être un dispositif d'affichage par exemple (écran, vidéoprojecteur...). Dans la suite de cet article, nous considérons le cas d'un ordinateur source et d'un vidéoprojecteur puits.

Cependant, depuis 20 ans, la spécification HDMI évolue et s'enrichit sans cesse de nouvelles fonctionnalités qui vont bien au-delà du simple transport de données audiovisuelles. À ce jour, la dernière version de HDMI est la version 2.1. Seule la version 1.3a est publiquement disponible [1]. Nous allons voir que de nombreux signaux et protocoles sont transportés par le câble HDMI, dont nous donnons la description succincte et les risques qui peuvent y être associés.

1.1 Câblage d’un connecteur HDMI

Le câblage d’un connecteur HDMI est donné dans la figure 2. Il comprend 19 conducteurs et un écran de blindage.

HDMI Connector Pinout-s

Fig. 2 : Connecteur HDMI.

1 : TMDS Data 2+

2 : Shield 2

3 : TMDS Data 2-

4 : TMDS Data 1+

5 : Shield 1

6 : TMDS Data 1-

7 : TMDS Data 0+

8 : Shield 0

9 : TMDS Data 0-

10 : TMDS Clock+

11 : Shield Clock

12 : TMDS Clock-

13 : CEC

14 : HEAC+

15 : DDC (I²C SCL)

16 : DDC (I²C SDA)

17 : Ground

18 : +5V

19 : Hot Plug/HEAC-/
MHL CBUS

1.2 Signaux TMDS (Transition-Minimized Differential Signaling)

Les signaux TMDS véhiculent l’image sur quatre paires différentielles : rouge, vert, bleu et horloge. Ils transportent également le son, qui est encodé dans les marges non visibles de l’image. Ces signaux sont unidirectionnels, de l’ordinateur vers l’écran. Ils sont également très rapides (pouvant atteindre 48 Gigabits par seconde en HDMI 2.1) et sont décodés à la volée par des circuits intégrés spécialisés, dans l’écran.

Ces signaux sont bien évidemment essentiels au bon fonctionnement du câble et présentent peu de risques de compromission, car les données qu’ils transportent font le plus souvent l'objet d'un traitement matériel et volatil. De plus, ce flux est unidirectionnel.

1.3 Signaux DDC (Display Data Channel)

Le signal DDC [2] est véhiculé par un bus I²C, utilisant deux fils dans le connecteur. Ce bus est un bus bidirectionnel half-duplex, couramment utilisé en électronique pour la communication entre microcontrôleurs. Dans le cadre du DDC (qui est aussi présent dans les connecteurs VGA et DVI, et transporté sur l'auxiliary channel du DisplayPort), le maître du bus est la carte vidéo de l'ordinateur. Dans l'écran, un certain nombre de circuits intégrés esclaves sont présents. Ces circuits sont détaillés ci-dessous.

1.3.1 EDID (Extended Display Identification Data)

EDID [2] est une structure de données contenant la description fonctionnelle de l’écran, notamment ses dimensions et les modes vidéo qu’il supporte. Cette structure de données est hébergée dans l'écran par une mémoire I²C (ou un microcontrôleur l'émulant) accessible sur les adresses A0h/A1h, et qui est alimentée par la carte vidéo par l’intermédiaire du câble (qui contient une ligne +5V). Cela permet la détection des caractéristiques de l’écran même lorsque celui-ci n’est pas branché au secteur.

Sa taille minimale est de 128 octets, mais elle est extensible jusqu’à 32 Ko. La plupart des écrans HDMI utilisent une taille de 256 octets. Cette structure de données est lue par la carte vidéo par l’intermédiaire du bus I²C afin qu’elle puisse déterminer automatiquement la résolution la mieux adaptée à celui-ci. Cette mémoire n’est normalement utilisée qu’en lecture par la carte vidéo, mais rien n’empêche cette dernière d’envoyer des commandes d’écriture dans cette mémoire. Selon les implémentations, certains écrans bloquent l’écriture, mais d’autres ne le font pas, permettant ainsi la modification du contenu de cette structure de données.

Un certain nombre de vulnérabilités ont été identifiées dans des parseurs EDID (qui font partie des pilotes de carte vidéo). Ainsi Andy Davis a présenté à Blackhat EU 2012 [3] un fuzzer EDID, qui lui a permis de déclencher des crashs dans le pilote Nvidia nvlddmkm.sys sous Windows 7. De même, Hyejin Jeong à DEFCON 27 [4] et Changhyeon Moon à HITB 2019 [5] ont présenté des travaux similaires sur le pilote i915 d'Ubuntu Linux. Enfin, en 2017 trois CVE ont été signalées sur le parseur EDID du noyau Android (CVE-2017-9722 [6], CVE-2017-11030 [7] et CVE-2017-11093 [8]).

1.3.2 DDC/CI (Display Data Channel/Command Interface)

DDC/CI permet d’envoyer des commandes I²C à l’écran (adresses 6Eh/6Fh) permettant par exemple de faire varier la luminosité, le contraste, et un grand nombre de paramètres, à l’instar de ceux accessibles par les menus intégrés à l’écran (menus On Screen Display). DDC/CI permet aussi de lire l’état des paramètres de l’écran, et embarque des mécanismes de détection de changement d’état. Ce protocole pourrait être détourné, par exemple, pour créer un canal de communication caché entre deux ordinateurs branchés au même écran.

1.3.3 HDCP (High-bandwidth Digital Content Protection)

HDCP est une option de HDMI et DVI permettant la protection des contenus numériques haute définition. Il s’agit d’un dispositif de protection des droits numériques (DRM pour Digital Right Management), dont l’activation peut être un prérequis pour le visionnage de médias haute définition (Blu-ray ou streaming HD par exemple). Pour protéger les contenus, le HDCP procède à un échange de clefs cryptographiques sur le bus DDC, afin d’établir une authentification mutuelle et des clefs de session, qui sont ensuite utilisées pour chiffrer le flux image TMDS. Les messages d'échange de clef HDCP sont faits sur le bus I²C aux adresses 74h/75h et 76h/77h.

1.3.4 SCDC (Status and Control Data Channel)

SCDC est une nouvelle interface de contrôle, accessible à l'adresse A8h/A9h, et qui est apparue dans la spécification 1.4b de HDMI. Elle permet de négocier avec l'écran la configuration de l'encodage des données TMDS, afin de permettre par exemple le support des écrans 3D, de codecs audio avancés, de gérer la latence des flux audio et vidéo, ou de permettre à l'écran de reporter à la carte vidéo le taux d'erreur du flux TMDS reçu. À l'instar de DDC/CI, ce protocole peut changer l'état de l'écran et pourrait potentiellement créer un canal de communication caché entre deux ordinateurs branchés au même écran.

1.3.5 Interfaces DDC propriétaires

Selon la documentation de dépannage (service manual) des constructeurs de certains écrans, il est possible de mettre à jour le firmware de leur contrôleur vidéo (qui est chargé entre autres d'afficher les menus « On Screen Display ») par l'intermédiaire de l'interface DDC, sur des adresses propriétaires. Cette pratique est illustrée dans la présentation d'Ang Cui à DEFCON 24 [9], qui a montré qu'il est possible de modifier le firmware à travers une interface DDC émulée par le hub USB intégré de l'écran. Ce type d'interface serait très utile à un attaquant, car elle permet de modifier l'implémentation de plusieurs interfaces avec la carte vidéo, comme DDC/CI, HDCP, SCDC ou CEC et d'ainsi rebondir vers d'autres ordinateurs.

1.4 Signaux CEC (Consumer Electronics Control)

Le signal CEC est véhiculé par un bus AV.link, utilisant un seul fil. Ce dernier est un bus bidirectionnel destiné à contrôler les équipements audiovisuels. Il véhicule des ordres similaires à ceux transmis par les télécommandes infrarouges de ces équipements, et peut donc se substituer à elles. Des vulnérabilités ont été découvertes sur cette interface, notamment des tests de fuzzing réalisés par Joshua Smith, présentés à DEFCON 23 [10], qui déclenchaient un crash sur un téléviseur. Deux CVE ont été publiées en 2017 sur l'implémentation CEC du noyau Linux d'Android (CVE-2017-9689 [11] et CVE-2017-9719 [12]).

1.5 HPD (Hot Plug Detect)

La fonction Hot Plug Detect permet à la carte vidéo de détecter qu’un écran vient d’y être branché. Cette détection entraîne généralement la lecture de l’EDID. Elle est assurée par un fil dédié du connecteur. Au sein de l’écran, ce fil est relié par une résistance de 1kΩ au +5V provenant du câble. C’est donc une fonction purement passive et essentielle au fonctionnement normal.

1.6 Signaux HEAC (HDMI Ethernet and Audio Return Channel)

HEAC utilise deux fils dans le connecteur HDMI, dont l'un d'entre eux (HEAC-) est celui déjà utilisé par HPD. Le second fil (HEAC+) est attribué à ARC (Audio Return Channel). Enfin, ces deux fils, s'ils sont assemblés pour former une paire différentielle à haute vitesse dans le câble HDMI, peuvent véhiculer HEC (HDMI Ethernet Channel). Ces trois signaux (HPD, ARC et HEC) peuvent cohabiter simultanément sur ces fils. Le bus CEC est utilisé pour négocier et établir les fonctionnalités HEAC.

1.6.1 ARC (Audio Return Channel)

Ce signal est un signal audio numérique au format S/PDIF, transmis en mode commun sur la paire HEAC (ou sur la ligne HEAC+). Il permet de faire un canal de retour pour le son, de l’écran vers la carte vidéo. Cette fonctionnalité permet donc d’équiper l’écran d’un microphone, pour la visioconférence par exemple. Cette partie du signal est supposée être unidirectionnelle.

1.6.2 HEC (HDMI Ethernet Channel)

Ce signal est un signal Ethernet 100Mbit/s, transmis en mode différentiel sur la paire HEAC. Il a en outre la particularité d'être bidirectionnel et full-duplex : les signaux Ethernet transmis de part et d'autre du câble se croisent et sont séparés par un astucieux circuit de différentiation (qui sépare le signal partant du signal arrivant, ainsi que le signal ARC). La couche physique est donc légèrement différente de celle de l'Ethernet 100BASE-TX, qui utilise normalement deux paires différentielles, une pour chaque direction. Ce lien Ethernet est destiné à servir de couche liaison pour un réseau IP entre plusieurs équipements reliés via HDMI, afin de partager un accès internet entre les équipements audiovisuels.

1.7 MHL (Mobile High-definition Link)

MHL est un standard permettant de brancher un téléphone portable à un écran par l’intermédiaire d’un câble reliant une prise micro-USB à un connecteur HDMI. Les signaux véhiculés par ce standard sont de nature différente de ceux du HDMI. Cependant, un écran compatible MHL va les détecter et les interpréter. Les signaux MHL sont composés d’une paire différentielle pour les signaux vidéo rapides (qui emprunte la paire Data 0 du câble, contacts 7 et 9), et d’un bus bidirectionnel monofilaire appelé CBUS (qui emprunte le contact 19). Ce bus remplit notamment la fonction de transfert des données DDC et CEC.

2. Implémentation du pare-feu par l'ANSSI

Afin de nous protéger contre les risques induits par ces technologies, nous proposons une première version d'un pare-feu dont le rôle est de filtrer les flux HDMI. Ce pare-feu se place en coupure sur le câble HDMI afin d’empêcher les protocoles indésirés d’atteindre l’écran, tout en laissant le passage à l’image et au son. L'objectif est donc de réduire la surface d'attaque en limitant les fonctionnalités du HDMI au strict minimum. Sa conception adopte un principe de simplicité et de sécurité.

concept

Fig. 3 : Concept du pare-feu HDMI.

2.1 Schématique et description

Le schématique de ce pare-feu est décrit dans la figure 4.

schemas v1

Fig. 4 : Schématique du pare-feu conçu par l’ANSSI.

Le port ordinateur sert à interfacer le filtre avec l'ordinateur de programmation lors de la phase de configuration, ou l'ordinateur source lors de la phase d'exploitation.

Le port écran sert à interfacer, lors de la phase d'exploitation, le filtre avec le dispositif d'affichage pour lequel le filtre aura été programmé lors de la phase de configuration.

Les différents signaux du câble HDMI sont traités de la manière suivante :

  • Les signaux TDMS (notés D0, D1, D2 et CK), qui transmettent l'image et le son sont bien évidemment essentiels au fonctionnement du système et présentent peu de risques de compromission, car les données très haut débit qu’ils transportent ne sont traitées que par des implémentations matérielles relativement simples, et le flux est unidirectionnel. En conséquence, le flux TMDS est le seul flux qui traverse le filtre sans être modifié. Une attention particulière doit être apportée au routage de ces signaux dans le filtre (impédance, symétrie), afin que le filtre ne génère pas de signaux parasites compromettants corrélés à l’image ;
  • Les signaux DDC (SCL et SDA) sont bloqués, afin qu’ils ne parviennent pas jusqu’à l’écran. Le filtre maintient toutefois la fonctionnalité EDID, car il intègre une mémoire EEPROM basique (de type 24C16) qui va jouer le rôle du stockage d'EDID et « émuler » le DDC de l'écran. Il faudra donc précharger les données EDID originales de l’écran protégé par le filtre lors d'une phase de configuration. Cette EEPROM est ensuite protégée en écriture par un interrupteur mécanique (SW1 sur le schéma) lors de la phase d'exploitation. Cela garantit une parfaite compatibilité du filtre tout en protégeant l’intégrité des données EDID. Une LED s'éclaire lorsque la mémoire est protégée ;
  • Le signal CEC présente un risque élevé. Il n’est donc pas routé dans le filtre, afin qu’il ne puisse pas servir de vecteur d’attaque ;
  • Le signal HPD est généré par une résistance de pull-up de 1kΩ (R1), qui suffit pour permettre la détection du branchement du filtre à la carte vidéo. Le signal n’est en revanche pas routé vers l’écran, ce qui permet notamment d'empêcher MHL de fonctionner, car son bus bidirectionnel CBUS emprunte ce fil ;
  • Le signal HEAC+ (désigné UTILITY dans le schéma) n'est pas routé, ce qui permet d'éliminer les risques associés à HEAC (ARC et HEC) ;
  • L'alimentation +5V fournie par la carte vidéo sert à alimenter la mémoire I²C et la résistance de pull-up HPD. Cette tension n'est normalement pas nécessaire au bon fonctionnement de l'écran, et peut être coupée par précaution. Cependant, nous avons constaté que certains matériels évolués (notamment des projecteurs ou des systèmes de visioconférence) utilisent la présence de cette tension pour détecter si une source est branchée. Nous avons donc mis un interrupteur sur la ligne +5V pour permettre de laisser passer ou de bloquer la tension 5V en fonction du besoin.

2.2 Phase de configuration

Un pare-feu est supposé être installé à demeure, par exemple pour un écran dans une salle de réunion, ou associé à un équipement qui ne change pas (par exemple un projecteur), car il est programmé pour correspondre à un modèle précis d’équipement, qu’il va protéger en se substituant à lui (du point de vue des éléments de configuration EDID). Il pourra être réutilisé sans reprogrammation, si l’on remplace l’écran par un autre du même modèle. En revanche, si le modèle d’écran change, il y a un risque d’incompatibilité du mode vidéo stocké dans le pare-feu avec celui supporté par le nouvel écran. Dans ce cas, il faut reprogrammer le pare-feu avec l’EDID du nouvel écran.

La procédure d'installation nécessite de copier les informations EDID stockées dans l'écran, et de les écrire dans la mémoire du pare-feu. Pour être mise en œuvre depuis un ordinateur, cette opération nécessite un accès direct au bus I²C de la carte vidéo. Sous Microsoft Windows, cette opération est impossible sans l'aide d'un accessoire matériel, car il n'existe aucune API système exposant cette interface, qui est gérée directement par les pilotes propriétaires de la carte vidéo. En revanche, sous Linux l'interface I²C des ports vidéo est exposée par /dev/i2c-n, n étant le numéro d'interface I²C, dès lors que le module noyau i2c-dev est chargé. Après avoir identifié quel port vidéo correspond au port HDMI, il est possible de lire et d'écrire des EDID, par exemple à l'aide du logiciel edid-rw [13].

La procédure d'installation du pare-feu est la suivante :

  1. Brancher l'ordinateur de programmation au port HDMI (ou DVI) de l’écran sur lequel le pare-feu doit être installé ;
  2. Lire l’EDID de l’écran et le stocker. En théorie, il n’y a pas besoin que l’écran soit mis sous tension, cependant sur certains téléviseurs cela peut être nécessaire afin d’obtenir un EDID valide ;
  3. Ouvrir les deux interrupteurs du pare-feu (mode programmable, pas de +5V vers l'écran) ;
  4. Brancher l'ordinateur de programmation sur le port ordinateur du filtre (J1) ;
  5. Écrire dans le filtre l’EDID précédemment lu. Il est important de vérifier que le moyen de programmation est bien branché au filtre, et non à l’écran, car dans le cas contraire cette opération pourrait endommager l’écran s'il n'est pas lui-même protégé en écriture ;
  6. Fermer l’interrupteur J1 en mode SECURE. Laisser l’interrupteur du +5V en position OFF ;
  7. Faire un test de fonctionnement : brancher un PC sur le port ordinateur du filtre et l’écran cible sur le port écran. Vérifier que la LED est allumée (elle confirme que le PC est branché du bon côté et que la mémoire est protégée en écriture). Vérifier que l’écran est détecté normalement par l’ordinateur et que l’image s’affiche normalement sur l’écran. En cas de problème de détection de l’ordinateur par l’écran (écran noir) il est possible de tenter de fermer l’interrupteur du +5V pour résoudre ce problème. Cette position n’est pas recommandée et ne doit être utilisée que si elle résout effectivement un problème avéré.

2.3 Discussion

Ce prototype de pare-feu HDMI a été industrialisé et a fait l'objet d'une présentation à la conférence SSTIC en 2021 [14] décrivant le problème de sécurité, les choix de conception et fournissant le schématique de la section 2.1.

Pour cette version ANSSI du pare-feu, le choix a été fait de réduire au minimum la surface d'attaque afin de simplifier la gestion des risques. Cela a impliqué ou introduit un certain nombre de contraintes. D'une part, la limitation des fonctionnalités du HDMI supportées au strict minimum essentiel entraîne de potentielles incompatibilités avec certains produits ou services. D'autre part, la limitation des fonctionnalités du filtre lui-même dans le but d'en minimiser la surface d'attaque permet de s'assurer que son utilisation n'introduit pas de nouvelles vulnérabilités, mais au prix de la flexibilité dans son utilisation et sa configuration.

Le pare-feu bloque le bus DDC, donc l’échange de clef HDCP avec l’écran ne peut pas avoir lieu. En conséquence, les fonctionnalités HDCP ne seront pas disponibles. Cela peut avoir pour conséquence que certains logiciels ou matériels de lecture de média refuseront de projeter des contenus haute définition sur l’écran protégé par le filtre.

D'autre part, dans le cas où le pare-feu HDMI est utilisé sur un lien DVI (par exemple en utilisant des câbles DVI-HDMI ou des adaptateurs DVI-HDMI pour insérer le boîtier entre l’écran et l’ordinateur), le filtre reste efficace, et la procédure d’installation est identique à celle du HDMI. En effet, un câble DVI inclut les signaux TMDS et DDC, qui sont gérés par le filtre, et il n’y a pas de protocoles à risques supplémentaires dans le DVI. Attention, certains signaux pouvant être présents sur un port DVI ne peuvent pas transiter par un port HDMI, ce qui peut entraîner des incompatibilités. Ces signaux sont :

  • Le signal VGA analogique (DVI-A). Ce signal ne pourra pas passer par le filtre ;
  • Les paires TMDS 3, 4 et 5 (DVI Dual Link) qui peuvent être nécessaires pour de très hautes résolutions avec un taux de rafraîchissement élevé, et qui n’existent pas dans le connecteur HDMI.

Cette version ANSSI du filtre apporte donc une solution simple et drastique au problème de sécurité considéré. La majorité des protocoles indésirés sont éliminés par une discontinuité électrique des signaux et le filtre ne comporte aucun nouvel élément actif procurant ainsi l'assurance d'une réduction de la surface d'attaque à son strict minimum.

3. Implémentation du pare-feu par CuVoodoo

Suite à la publication de la version ANSSI à la conférence SSTIC 2021, une version 2 du pare-feu HDMI par CuVoodoo [15] a été réalisée. Elle permet de s'abstraire de certaines limitations de l'implémentation de la version ANSSI du pare-feu en fournissant plus de flexibilité, en contrepartie d'une augmentation de sa complexité, et donc du risque de vulnérabilité.

front v2-s

Fig. 5 : Photographie du pare-feu conçu par CuVoodoo.

3.1 Schématique et description

schema v2-s

Fig. 6 : Schématique du pare-feu conçu par CuVoodoo.

Les signaux TDMS traversent comme auparavant le filtre sans être modifiés, laissant passer le flux audiovisuel. Les autres signaux (DDC, CEC, HEAC, et 5V) passent dorénavant par des interrupteurs. Par défaut, les interrupteurs sont ouverts, bloquant physiquement toute communication, comme c'est le cas pour la première version. Mais si l'utilisateur requiert les fonctionnalités offertes par ces interfaces, il peut basculer les interrupteurs individuellement pour permettre la communication. Ceci augmente la surface d'attaque de l'écran et de la carte vidéo, mais la décision de prendre ce risque revient à l'utilisateur.

La seconde amélioration simplifie grandement la procédure d'installation. Au lieu d'une mémoire EEPROM, un microcontrôleur prend en charge la programmation de l'EDID.

3.2 Procédure d’installation

Cette procédure d'installation n'a besoin d'être effectuée qu'une seule fois (par écran à protéger) et ne requiert pas d'outils supplémentaires.

  1. Avant de brancher l'écran au pare-feu, l'interrupteur EDID/7 doit être sur la position ALLOW/ON ;
  2. Dès que la carte vidéo est ensuite branchée sur le pare-feu, celui-ci copiera directement l'EDID de l'écran dans sa mémoire interne ;
  3. Une fois la LED rouge éteinte, la copie est effectuée et l'interrupteur EDID/7 peut être à nouveau basculé sur BLOCK/OFF.

Le microcontrôleur prendra le rôle de mémoire et permet à la carte vidéo de lire l'EDID de manière sécurisée. Cette mémoire est protégée contre l'écriture, et aucune autre fonction que l'EDID n'est accessible sur l'interface DDC. De plus, le nom de l'écran inscrit dans l'EDID copié terminera par '|' pour indiquer que le pare-feu est présent.

Si l'interrupteur EDID/7 reste sur la position ALLOW/ON, l'écriture de l'EDID du pare-feu est permise. La méthode d'écriture reste identique à la procédure d'installation du pare-feu par l'ANSSI. Ceci permet de corriger ou modifier les résolutions, modes, et fonctions annoncées par l'écran.

Si les interrupteurs SDA/2 et SCL/3 sont sur la position ALLOW/ON, la carte vidéo sera directement connectée à l'interface DDC de l'écran. Le pare-feu ne filtrera plus cette communication, et ne mettra plus à disposition une copie sécurisée de l'EDID. Mais le HDCP et les autres fonctions permises sur l'interface DDC sont à nouveau disponibles. Ceci augmente également la surface d'attaque, mais c'est à nouveau un risque que l'utilisateur aura le choix de prendre.

3.3 Code source

Le microcontrôleur dans cette version Cuvoodoo du pare-feu HDMI pose un risque supérieur à la simple mémoire EEPROM de la première version. C'est pourquoi le code source de son micrologiciel est ouvert [16], permettant à chacun de vérifier qu'il ne fait rien de plus que de copier l'EDID.

Les fichiers sources pour le matériel sont également ouverts [17], ainsi que les documents de fabrication [18]. Ceci permet à d'autres de modifier et produire leur propre version correspondant à leurs besoins.

Conclusion

Les consortiums d'industriels en charge de la spécification des protocoles ont souvent tendance à essayer de proposer un protocole universel compatible à tous les usages identifiés et futurs. Par conséquent, les fonctionnalités sont nombreuses et les protocoles de plus en plus génériques et extensibles.

Pour l'utilisateur, cela constitue probablement un avantage puisqu'il n'aura plus besoin de multiplier les câbles et les adaptateurs. En revanche, pour gérer les risques de sécurité, cela peut vite devenir chaotique.

Le HDMI est un protocole dédié au transfert de données audiovisuelles numériques qui en réalité embarque pas moins de huit protocoles numériques supplémentaires. Chaque protocole supplémentaire implique la présence de piles protocolaires qui peuvent contenir des vulnérabilités. L'utilisation d'équipements compatibles avec HDMI expose donc ces piles protocolaires et il est difficile d'en garantir l'innocuité.

Afin de répondre à cette problématique, le laboratoire sécurité des technologies sans-fil de l'ANSSI a conçu le prototype d'un pare-feu pour le HDMI coupant physiquement les protocoles indésirés afin de réduire la surface d'attaque : une solution minimaliste, mais assez contraignante.

La publication de ce travail a permis à CuVoodoo de réaliser de nouvelles versions du pare-feu introduisant plus de flexibilité en contrepartie d'une complexité pouvant exposer une plus grande surface d'attaque. Ces versions sont donc plutôt destinées à des utilisateurs avertis et tout à fait idéales à des fins de recherche et de prototypage autour du protocole HDMI.

Le HDMI est loin d'être le seul standard de connectique « à tiroirs » incluant ou supportant d’autres standards inattendus. L'USB Type-C, par exemple, rencontre beaucoup de succès suite à l'adoption par l'Union Européenne le 07/12/2022 de la directive relative à l'harmonisation des législations des États membres concernant la mise à disposition sur le marché d'équipements radioélectriques [19] imposant cette connectique pour les chargeurs. Une approche similaire pourrait ainsi être envisagée pour faciliter la gestion des risques introduits par ces protocoles très riches en fonctionnalités.

Références

[1] HDMI 1.3a specification :
https://web.archive.org/web/20160305072940/http://www.microprocessor.org/HDMISpecification13a.pdf

[2] Standards VESA : https://vesa.org/vesa-standards/

[3] Andy Davis - Blackhat EU 2012 :
https://www.blackhat.com/html/bh-eu-12/bh-eu-12-briefings.html#davis

[4] Hyejin Jeong - DEFCON 27 :
https://confs.space/conf/defcon-27-iot-village/hack-dmi-pwning-hdmi-for-fun-and-profit/

[5] Changhyeon Moon - HITB 2019 :
https://conference.hitb.org/hitbsecconf2019ams/sessions/hackdmi-pwning-hdmi-for-fun-and-profit/

[6] CVE-2017-9722 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9722

[7] CVE-2017-11030 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11030

[8] CVE-2017-11093 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11093

[9] DEFCON 24 : https://defcon.org/html/defcon-24/dc-24-speakers.html#Cui

[10] DEFCON 23 : https://defcon.org/html/defcon-23/dc-23-speakers.html#Smith

[11] CVE-2017-9689 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9689

[12] CVE-2017-9719 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9719

[13] Code source edid-rw : https://github.com/bulletmark/edid-rw

[14] Conférence SSTIC 2021 : https://www.sstic.org/2021/presentation/un_pare_feu_pour_le_hdmi/

[15] Vidéo de présentation de la version 2 du pare-feu HDMI par CuVoodoo :
https://www.cuvoodoo.info/cuvoodoo-gadget-hdmi-firewall-v2/

[16] Code source du micrologiciel : https://git.cuvoodoo.info/kingkevin/stm8s/src/branch/hdmi_firewall

[17] Code source du hardware : https://git.cuvoodoo.info/kingkevin/board/src/branch/hdmi_firewall

[18] Documents de fabrication : https://git.cuvoodoo.info/kingkevin/board/releases/tag/hdmi_firewall_v2

[19] Directive relative à l'harmonisation des législations des États membres concernant la mise à disposition sur le marché d'équipements radioélectriques : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=uriserv%3AOJ.L_.2022.315.01.0030.01.FRA&toc=OJ%3AL%3A2022%3A315%3ATOC



Article rédigé par

Par le(s) même(s) auteur(s)

Agressions électromagnétiques et risques SSI

Magazine
Marque
MISC
HS n°
Numéro
16
Mois de parution
octobre 2017
Spécialité(s)
Résumé

Dans la culture populaire, les agressions électromagnétiques, souvent vues comme des impulsions désactivant ou détruisant les équipements électroniques dans un rayon de plusieurs kilomètres, relèvent de la science-fiction. Dans la littérature scientifique, la menace principalement considérée impacte majoritairement la disponibilité. Mais avec les évolutions technologiques des moyens d’émission, de nouvelles attaques sont à la portée de profils d’attaquants non étatiques. Quels impacts peuvent être envisagés ? Comment en estimer les risques pour la SSI ?

Les derniers articles Premiums

Les derniers articles Premium

PostgreSQL au centre de votre SI avec PostgREST

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Dans un système d’information, il devient de plus en plus important d’avoir la possibilité d’échanger des données entre applications. Ce passage au stade de l’interopérabilité est généralement confié à des services web autorisant la mise en œuvre d’un couplage faible entre composants. C’est justement ce que permet de faire PostgREST pour les bases de données PostgreSQL.

La place de l’Intelligence Artificielle dans les entreprises

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

L’intelligence artificielle est en train de redéfinir le paysage professionnel. De l’automatisation des tâches répétitives à la cybersécurité, en passant par l’analyse des données, l’IA s’immisce dans tous les aspects de l’entreprise moderne. Toutefois, cette révolution technologique soulève des questions éthiques et sociétales, notamment sur l’avenir des emplois. Cet article se penche sur l’évolution de l’IA, ses applications variées, et les enjeux qu’elle engendre dans le monde du travail.

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 68 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous