Des failles dans les téléviseurs connectés LG permettent d’écouter leur environnement
Entre failles et publicités
Illustration : Flock
Vincent Hermann
Le 09 septembre à 16h42
En juillet, une polémique avait éclaté autour des écrans LG pour ordinateurs : l’installation automatique du pilote provoquait l’apparition d’une publicité pour l’antivirus McAfee. Les pratiques du constructeur ont été épinglées dans une nouvelle vidéo, mais LG dément tout problème.
Des failles dans les téléviseurs connectés LG permettent d’écouter leur environnement
Entre failles et publicités
Illustration : Flock
En juillet, une polémique avait éclaté autour des écrans LG pour ordinateurs : l’installation automatique du pilote provoquait l’apparition d’une publicité pour l’antivirus McAfee. Les pratiques du constructeur ont été épinglées dans une nouvelle vidéo, mais LG dément tout problème.
Sécurité
Sécurité
7 min
LG a été sous un feu nourri de critiques en juillet. Lors du branchement d’un écran LG sur un ordinateur, un signal était envoyé à Windows Update pour récupérer automatiquement le pilote. Une opération courante, qui évite à l’utilisateur d’aller le chercher manuellement.
LG avait détourné ce mécanisme pour installer aussi un composant qui provoquait l’affichage d’une publicité pour McAfee. La documentation de Microsoft précise pourtant de faire attention à ce genre de pratique. La firme avait d’ailleurs fini par intervenir, LG mettant fin à l’opération, avec une image entachée.
Ce comportement avait été mis en avant par Gamers Nexus dans une vidéo expliquant le problème. Or, la chaine vient de remettre le couvert, en s’attaquant cette fois aux téléviseurs de la marque.
Dans sa nouvelle vidéo (vue plus de 3 millions de fois à l’heure où nous écrivons ces lignes), Gamers Nexus expose pendant 135 minutes l’étendue de ses découvertes, faites en collaboration avec Level1Techs et des chercheurs en sécurité indépendants. La chaîne met en cause le comportement réseau et logiciel des téléviseurs sous webOS, notamment des modèles OLED de la gamme G5.
Des comportements étranges…
La vidéo de 2h15 plonge profondément dans les détails. Parmi les constats majeurs de la chaîne : le fait que les téléviseurs testés (des modèles OLED) captent l’audio dans la pièce, même quand l’appareil est en veille. D’après les tests réalisés, les téléviseurs enregistrent le son à travers le micro même quand la connexion est coupée, stockant les données localement en attendant que l’accès à internet soit restauré.
Les testeurs ont également utilisé le logiciel Wireshark pour analyser les paquets de données envoyés par la télé. Les résultats auraient montré un balayage actif du réseau local, notamment pour cartographier les appareils voisins. Ce balayage collecterait au passage les adresses IP des appareils connectés, de même que les noms et intensités de signal des réseaux Wi-Fi détectés, ainsi que leurs données de localisation.
Selon Gamers Nexus, les données ainsi recueillies alimentent LG Ad Solutions, la filiale publicitaire du groupe. LG aurait écoulé 216 millions de téléviseurs connectés dans le monde, tandis que la filiale revendiquerait 363 millions d’appareils secondaires pouvant être ciblés individuellement, dans les seuls États-Unis. On ne parle donc pas uniquement d’appareils détectés, mais de ceux sur lesquels une publicité peut être envoyée.
La technique n’est pas nouvelle, chez LG. Le constructeur utilise depuis des années un mécanisme nommé Automated Content Recognition (ACR, non spécifique à LG), chargé de générer des empreintes numériques, pour récupérer – entre autres – les habitudes de visionnage. Le travail mené par Gamers Nexus va cependant plus loin.
Le plus gros problème rencontré par la chaîne réside dans la sécurité. Plusieurs failles ont été détectées dans webOS, le système d’exploitation propre à LG, que le constructeur fournit dans ses TV connectées. Les testeurs sont parvenus à les exploiter, débloquant des capacités d’exécution de code arbitraire à distance. Ils s’en sont servi, entre autres, pour récupérer les données audio justement enregistrées par le téléviseur quand la connexion internet était coupée.
Les failles ont été transmises à LG sans révélation publique et seraient en cours de correction.
… réfutés par LG
En 48 heures (la vidéo a été publiée le 7 septembre), ces informations ont eu le temps de ressortir dans plusieurs médias. Initialement, LG se refusait à tout commentaire, mais le constructeur a fini par sortir de sa réserve auprès de plusieurs sites, dont MacG.
Selon LG, les conversations ambiantes ne sont ni enregistrées ni transmises dans les conditions normales d’utilisation. Pour que le processus se déclenche, il faut que l’utilisateur l’active volontairement, par exemple via la touche spécifique de la télécommande. Le constructeur réfute toute écoute passive et automatique de ce qui se passe autour de ses télés connectées.
L’écoute peut en revanche se faire si la fonction « Hi LG » est activée. Le comportement serait alors le même que n’importe quel autre assistant vocal : une écoute locale passive, devenant active quand les mots-clés sont prononcés. Quand aucun mot-clé n’est détecté, les données stockées temporairement sont supprimées et rien n’est transmis, assure LG.
Le constructeur affirme également que les données récupérées sur le réseau sont standards. Détecter les appareils connectés permet notamment de partager du contenu et d’utiliser d’autres fonctions liées à la maison connectée. Autre affirmation : tout ce qui touche à la personnalisation des publicités et, de manière générale, à l’ACR, ne peut fonctionner qu’avec un accord explicite de l’utilisateur. Celui-ci peut révoquer cette autorisation à tout moment dans les réglages de l’appareil.
Bien que ces comportements puissent entrer dans la catégorie « pratiques courantes », la réponse de LG est incomplète. Ainsi, pas un mot sur les failles de sécurité, alors qu’elles ont permis la récupération de données pouvant s’avérer sensibles. Exploitées, ces failles pourraient permettre à des pirates de transformer ces appareils en autant de dispositifs d’écoute.
Le Cyber Resilience Act en embuscade
À noter que Gamers Nexus avait déjà épinglé les téléviseurs LG en juillet pour les problèmes d’écoute. Ils notaient effectivement que l’on pouvait désactiver la reconnaissance vocale, coupant du même coup toutes les fonctions de type IA. LG, là aussi, avait fini par répondre à plusieurs médias, dont nos confrères de MacG : « LG Electronics (LGE) réaffirme que les téléviseurs LG ne collectent, n’enregistrent ni ne stockent les conversations ambiantes. La reconnaissance vocale est une fonctionnalité optionnelle, lancée par l’utilisateur, qui traite les données vocales uniquement lorsqu’elle est activée par l’utilisateur pour répondre à une demande spécifique. Les clients peuvent utiliser les fonctionnalités Smart TV sans activer la reconnaissance vocale ».
La succession des vidéos de Gamers Nexus provoque, sans surprise, de nombreuses discussions et écorne l’image du constructeur. Sur Reddit ou les réseaux sociaux, de nombreuses personnes réfléchissent désormais à la connexion de leur téléviseur, LG ou non. Outre les choix faits par les constructeurs, la sécurité même du système d’exploitation interroge et beaucoup se demandent si elle est gérée sérieusement.
Ces questions fusent autour des appareils connectés depuis longtemps. Elles ont largement alimenté la réflexion ayant conduit l’Europe à adopter le Cyber Resilience Act, qui va franchir une étape majeure ce 11 septembre. Mais à compter de décembre 2027, les constructeurs seront pleinement responsables de la sécurité de leurs produits, dès lors qu’ils contiennent une composante numérique. Les téléviseurs connectés seront bien sûr concernés, d’autant plus que le CRA sera rétroactif et s’appliquera sur tous les appareils en cours de commercialisation, pas uniquement les nouveaux.
Commentaires (51)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 9 septembre à 17h26
Le 9 septembre à 17h54
Donc c'est certainement pas limité à LG et pas près de s'arrêter.
Le 9 septembre à 18h51
L'exemple qui me vient en tête c'est ce qu'a fait la FCC avec les routeurs aux US (pour des histoires de fréquences radio) mais j'ai rien vu de tel dans le CRA ?
Ca par contre je suis malheureusement d'accord : Quand tu achète en "tout connaissance de cause ..." l'appareil au constructeur qui t'espionne... pas sur que ce soit considéré comme une faille :-(
(Le root de sa tv en devient d'autant plus crucial, mais bon je me fait pas d'illusion on sera 5 à le faire...)
Le 9 septembre à 23h04
Le 10 septembre à 02h22
Le 10 septembre à 08h22
Le 10 septembre à 09h08
Le 10 septembre à 09h21
Le 9 septembre à 18h52
En l'occurence dans le cas présent, les chercheurs ont trouvé des failles et, en toute logique, LG devrait les remonter à l'ENISA dès le 11 septembre sous peine d'avoir à subir l'article 64 du CRA.
Le 10 septembre à 08h20
Le modèle de menace du CRA, c’est que la menace est extérieure, et que le constructeur est digne de confiance. Quant au consommateur, il n’a aucune voix au chapitre. Le CRA va certes amener une amélioration de la sécurité des objets, mais va aussi enlever toute liberté au consommateur, car absolument rien n’a été prévu de ce côté là.
Le 10 septembre à 09h27
Ce qui me fait peur c'est pas la technologie du secure boot en tant que telle, c'est que moi, propriétaire & utilisateur n'ai pas les clés requises pour reconstruire un firmware signé.
Les autorités comme les fabricants se rejoignent dans la défiance qu'ils ont de leur utilisateurs, et le fait que ce soit entériné dans le CRA ça m'énerve profondément.
On a tendance à être fataliste sur l'informatique en France mais AJA que en Allemagne , même en fibre / gpon /xsgpon /... ben les gens pouvaient avoir leurs propres routeur et que c'était normal - t'a pas l'impression de passer pour un hacker à capuche parce que tu veux que ton serveur DHCP marche et que ton DNS ne mente pas.
On peux & sait faire les choses bien. Juste on veux pas.
Le 10 septembre à 20h01
le secure boot est un moyen parmi d'autres de sécuriser un appareil mais pas forcément obligatoire.
Il faut bien comprendre que l'objectif est de sécuriser contre une menace qui vient d'un réseau informatique.
Si, par exemple, la mise à jour du firmware n'est possible que via une liaison locale, USB, série, jtag..., ce n'est pas une obligation.
Et il reste toujours possible, comme sur les PC, de permettre explicitement aux utilisateurs de changer le système.
Il faut bien se rendre compte que le CRA est une aubaine commerciale et que les prescripteurs de secure boot ne sont pas neutres.
Le 11 septembre à 06h47
La conséquence, c’est que tout le monde (en tout cas en France, mais je suppose que c’est pareil ailleurs, au moins en Europe) est en train de mettre en place des secure boot (je suis en plein dedans au boulot) alors qu’avant tout le monde s’en foutait. Et que du coup, tout ce qui consiste à remplacer le firmware ne sera plus possible, car t’as pas les clés.
Comme dans le CRA, rien n’a été prévu pour le consommateur, c’est lui qui l’aura dans le baba. On pourrait mettre en place un secure boot où le consommateur pourrait changer les clés, avec des procédures spécifiques, mais c’est beaucoup plus complexe, donc ce n’est pas ce qui va être fait.
Le 11 septembre à 08h10
Annexe 1, partie 2:En outre, la mise à jour par OTA doit pouvoir être débrayée et c'est écrit dans le CRA.
Annexe 1, §2 c:Par contre, le CRA t'impose d'informer pro-activement tes clients sur les failles qui sont présentes sur les produits mis sur le marché ou toujours supportés:
Ce qui est obligatoire est de proposer des nouvelles mises à jours de sécurité à titre gracieux aux clients pendant la mise sur le marché et pendant la période d'assistance. OTA ou pas, il faut communiquer.
Article 13, §8 (extraits) :Article 13, §9 :Tu dois donc avoir une possibilité pour tes clients d'être au courant des failles et des mises à jour de sécu, via une page web sur ton site, qui peut leur être réservée. Et, si ils se sont enregistré, tu peux aussi les informer via leur adresse de contact.
Si tu fais des mises à jour OTA, les clients doivent tout de même savoir quelle faille a été corrigée. En cas de rétention de ce type d'information, c'est l'article 64 qui s'applique.
La possibilité de débrayer les mises à jour automatiques est primordiale car, dès que des appareils sont chez des clients pro, les DSI n'apprécient pas d'avoir des appareils qui contactent l'extérieur et qui modifient leurs firmware à la volée car cela correspond pile à un cheval de Troie.
Le 11 septembre à 13h15
Annexe 1, part 1.f : Protéger l’intégrité du programme, sans recourir à secure boot, c’est chaud.
Annexe 1, part 2.2 part 2.8 Donc oui, le CRA n’impose pas dans le texte secure boot ou l’OTA, mais dans les faits, si tu vends un truc à des particuliers, je ne vois pas comment tu fais pour y échapper dès lors que ton objet est connecté à internet. Et si tu vends à des pros, à part dans certains domaines bien spécifiques (je pense à la banque), c’est grosso-modo pareil, dès lors que c’est à toi de t’assurer que les trucs que tu as vendus sont à jour, l’OTA me semble le seul moyen raisonnable d’y parvenir.
Honnêtement, si tu as une analyse sérieuse et reconnue qui dit l’inverse, ça m’intéresse de voir leurs arguments, car autant l’OTA que le secure boot, ça a de grosses implications en terme de production et de coûts, et que s’il y a moyen de s’en passer j’ai un patron qui sera très content. Mais ce n’est pas trop l’avis des formateurs cyber qu’on a pu interroger, ni la tendance à l’œuvre dans le secteur.
Peut-être que je généralise un peu trop le cas particulier que je connais professionnellement, c’est possible. Merci de m’avoir rappelé qu’il faut en plus que l’utilisateur puisse débrayer les màj, j’avais zappé. Mais je t’assure que personne n’y va de gaieté de cœur, mais que les gens y vont quand même, car l’analyse couramment partagée dans l’embarqué, c’est que c’est ce qu’il faut mettre en place (secure boot + OTA).
Le temps où tu pouvais reflasher le firmware de ton routeur ou de ta caméra, malheureusement, semble bientôt révolu… Je préfèrerais mille fois que tu aies raison et qu’on continue d’avoir des objets qu’on achète qu’on pourra hacker tranquillement, comme mon vieux nas D-Link où il était super simple de resouder un TTL et de remplacer le firmware. Mais mon ressenti/analyse, c’est que ce n’est pas la direction qu’on prend. Et j’en veux au CRA d’avoir complètement négligé que quand tu achètes un truc, c’est toi le propriétaire, et que donc tu devrais avoir le choix du logiciel qui tourne dessus.
Le 11 septembre à 18h05
Comme tu le dis, c'est un tout donc les articles que j'ai cité s'appliquent et donc les mises à jour automatiques OTA doivent être débrayables par l'utilisateur: ce n'est pas une option, c'est une obligation.
Et je ne suis pas d'accord avec ton interprétations de l'Annexe 1, part 1.f : l'article parle des données et non des programmes. Il s'agit ici de protéger les données de l'utilisateur contre le vol ou la modification et d'être en mesure de le détecter.
Annexe 1, part 2.2 : je ne vois pas ce que cet article vient faire dans ta démonstration
part 2.8 : je ne vois pas ce que cet article vient faire dans ta démonstration
Il faut bien comprendre une chose: le CRA pose un cadre pour protéger les appareils et les données personnelles qui y sont contenues le cas échéant, contre les attaques venant d'un réseau. C'est dans le nom: cyber resilience
Le secure boot protège contre des attaques physiques, ce qui est mieux mais cela n'est pas imposé et ne se justifie pas pour n'importe quel appareil.
Le 13 septembre à 07h00
Le CRA n'a peut-être pas tant que ça négligé les possibilités de choix de l'utilisateur, mais certains fabricants et vendeurs de secure boot l'ont peut-être interprété d'une manière qui les arrange.
Modifié le 13 septembre à 10h53
Je pense en effet que les fabricant de solutions de secure boot vendent leurs produit comme la solution miracle pour être conforme alors que ce n'est dans la plus part des cas q'un pansement sur une jambe de bois.
@white_tentacle
L'idée première du CRA est de rendre les appareils connectés résistants contre les attaques cyber, pas contre le side loading via une interface local. Le concept primordial est, en anglais: « secure by design » et le mot clef est: cybersécurité.
Cela veut dire que la priorité numéro 1 est de concentrer les efforts sur les interfaces et les api pour qu'il ne soit pas possible d'en abuser.
Mettre un secure boot n'a pas de sens si n'importe quel pirate en herbe est en mesure de faire de l'injection SQL. C'est là pour autant que résident encore beaucoup de failles encore maintenant.
C'est aussi la gestion de l'imprévu en évitant les dépassements de tampon.
Combien de développeurs utilisent encore strcpy en langage C, sur des chaînes de caractères non vérifiées ? Encore trop quand on voit les alertes pour dépassement de tampon.
Et avant de songer à mettre un secureboot, il faut déjà penser à sécuriser le ssh quand il y en a un, imposer à l'utilisateur de changer tous les mots de passe par défaut avant de permettre l'utilisation de l'appareil (mode configuration avec fonctions limitées), ne pas utiliser les mêmes secrets pour tous les appareils en usine...
Le secure boot, je le répète, c'est l'étape finale optionnelle qui protège contre les attaques physiques mais qui risque de violer le CRA si l'utilisateur final ne peut pas choisir quel firmware sera installé.
A partir du moment où les données sont chiffrées, aucun firmware alternatif ne peut y accéder donc on est bon.
@Inodemus
je suis tout à fait d'accord avec ta conclusion. L'idée est de donner la main à l'utilisateur final.
Le 13 septembre à 08h35
@Inodemus Pour moi le CRA a négligé le consommateur final. Il a créé plein d’obligations pour le constructeur qui le poussent à verrouiller au maximum son produit, et n’a créé aucun droit supplémentaire pour l’utilisateur pour compenser cela (je ne considère pas le droit de différer les màj comme compensant quoi que ce soit). Le droit de changer le firmware n’a (malheureusement) jamais existé au sens où il n’est pas protégé, mais dans les faits c’est possible et ce n’est pas interdit. L’application du CRA va rendre cette possibilité beaucoup plus dure, car pour le fabricant, il est plus simple d’empêcher toute modification du produit, intentionnelle de l’utilisateur ou non. Le fabricant choisit généralement la solution la moins chère pour lui. Je t’assure que même sans volonté de bloquer (c’est mon cas, et comme dit je mets ça en place au taf – on est sur du B2B donc j’ai moins mauvaise conscience), à la fin le produit sera verrouillé car c’est ce qui est plus facile. Empêcher toute modification non autorisée par le fabricant permet d’empêcher toute modification non autorisée par l’utilisateur, et coûte beaucoup moins cher que de s’assurer que chaque modification autorisée l’est par l’utilisateur uniquement, et non par un tiers qui se fait passer pour l’utilisateur. C’est un coût et un risque supplémentaire que la plupart n’assumeront pas.
Modifié le 13 septembre à 09h48
Soit la modification non autorisée arrive avec une mise à jour et il y a d'autres moyens de vérifier l'intégrité, soit elle arrive par une faille et ça n'aide en rien, surtout pour les configurations, car c'est alors le firmware authentifié actuel qui réalise les modifications et il en a le droit, soit c'est du flashage physique et on peut difficilement dire que ce n'est pas l'utilisateur qui l'a voulu.
Le premier cas est un vieux problème avec des solutions éprouvées, le 2ème n'est pas traitable de manière certaine puisque par définition pas volontaire, le 3ème traite des accès physiques non autorisés et ne paraît pas pertinent pour du matériel grand public. Où est-ce que le secure boot nous sauve pour les 2 premiers cas ? Pourquoi une vérification d'intégrité des mises à jour et des droits d'accès en écriture bien définis, qu'il faut quand-même faire de toute façon sous peine de se retrouver avec du matériel briqué, ne suffiraient pas ?
Ce n'est pas non plus correct de dire qu'empêcher les modifications non autorisées par l'utilisateur est un sous-ensemble d'empêcher les modifications non autorisées par le fabricant, ce sont plutôt 2 ensembles qui se croisent, et c'est visiblement l'utilisateur qui doit pouvoir décider à quel point ils se croisent. D'où l'obligation de pouvoir désactiver les mises à jour si l'utilisateur n'autorise pas le fabricant à faire des modifications.
Le 14 septembre à 06h34
C’est pour ça que je demandais à wanou s’il avait des exemples d’analyses de risque un peu sérieuses qui ont conclu à la non nécessité d’un boot sécurisé dans le cadre du CRA. Comme dans toute analyse de risque, il y a toujours une part d’arbitraire et un peu de flou, mais je suis sincèrement curieux de voir les arguments avancés pour dire « notre process de màj est blindé, on peut se passer d’authentifier le bootloader ». Je l’envisage sur les trucs qui auraient un switch hard pour empêcher le reflashage, par exemple, mais le problème de ça c’est que c’est contradictoire avec l’obligation de diffusion par défaut des correctifs par le fabricant, sans intervention de l’utilisateur.
Je ne vois pas, dans le CRA, de points qui iraient dans ce sens là. Un objet qui n’autorise aucune modification par l’utilisateur, mais en autorise par le fabricant (par exemple, le fabricant décide de désactiver une fonctionnalité par màj) est conforme au sens du CRA (probablement que ça va poser des problèmes du point de vue du droit de la consommation, heureusement, mais c’est un autre texte). Le fabricant est aussi heureusement libre de t’autoriser à faire des modifications (comme, par exemple, ouvrir le bootloader comme le font certains fabricants de téléphone), mais il est aussi libre de te les interdire.
On pourrait envisager que cette liberté de faire des modifications soit un argument commercial, et que du coup certains constructeurs la conservent. Je serai le premier à abonder dans ce sens, mais ce n’est pas la tendance que je vois à l’œuvre aujourd’hui.
@wanou Je ne sais pas ce qui te fait dire ça. Par curiosité, voilà ce que répond le search assist de duckduckgo :
« L'obligation numéro 1 du Cyber Resilience Act (CRA) est de garantir que la cybersécurité soit intégrée dès la conception des produits comportant des éléments numériques. Cela inclut la mise en place de processus pour détecter et corriger les vulnérabilités tout au long du cycle de vie du produit. ».
Et ça me semble correspondre beaucoup plus à l’esprit, en tout cas à ce que j’en ai compris.
Après, oui, la transparence fait partie des obligations du CRA. Comme un des nombreux moyens à mettre en œuvre afin d’arriver à l’objectif.
Là-dessus tu négliges un point important du CRA. Par défaut, chaque fois que c’est possible, les mises à jour / correctifs doivent se déployer sans intervention de l’utilisateur. Le fait de pouvoir les décaler dans le temps est une possibilité, offerte à l’utilisateur, comme tu l’as rappelé, mais ce n’est pas le comportement par défaut. Là encore, l’idée sous-jacente, c’est que si ce n’est pas fait sans intervention de l’utilisateur, ça ne sera pas fait, et donc l’objet continuera de représenter un risque pour l’écosystème auquel il est relié (c’est à dire la plupart du temps, tout internet).
Ça c’est le cas si tu ne peux pas déployer les màjs automatiquement. Il faut bien comprendre que l’information de tes clients ne te dispense pas de l’obligation de t’assurer que les objets sont bien à jour. La lecture que j’en fais moi (mais qui est partagée par d’autres personnes que j’ai pu interroger sur le sujet), c’est que s’il est possible de part la nature de l’objet de faire de l’OTA, mais que tu te contentes d’un process de màj manuel avec information de l’utilisateur, globalement tu ne seras pas conforme. Par contre, si le contexte fait que toi, en tant que fabricant, tu ne peux pas déployer automatiquement la màj (par exemple, l’objet est un distributeur bancaire, fonctionnant sur un réseau isolé), là effectivement tu peux te contenter de donner à ton client les infos, éléments et la procédure, et faire reposer sur lui la charge de la màj. Mais c’est en quelque sorte une stratégie de repli, quand tu ne peux pas faire autrement.
Tu as raison sur le fait que la conformité au CRA concerne tout le SI, par contre, le CRA vise seulement à ce que le SI s’assure que tes données ne fuitent pas à un tiers non autorisé. Il y a quand même de mémoire une petite partie qui parle, pour certaines catégories, de minimisation des données collectées, dans le but que si ça fuite, ça ne soit pas trop. Mais celui qui te garantit l’accès et l’effacement, c’est le RGPD. Le CRA te garantie juste que tu seras informé des problèmes de sécurité et que tu auras des mises à jour de sécurité pendant une durée définie (de mémoire elle dépend des classes de produit ou d’engagement contractuels, je n’ai plus les chiffres en tête).
Après, c’est sûr que si le CRA est appliqué avec autant de sérieux et de sévérité que le RGPD, je m’inquiète pour rien…
Modifié le 14 septembre à 18h20
Si l'utilisateur ne veut pas que le fabricant modifie son appareil, en le faisant quand-même le fabricant viole la disposition que j'avais cité. A moins qu'une autre disposition l'y autorise par exception à celle-ci, c'est une modification non autorisée par l'utilisateur. C'est sûrement pour ça qu'il est aussi explicitement demandé de pouvoir désactiver les mises à jour (un opt-in révocable).
Je m'attendais un peu à ta réponse sur l'utilité du secure boot, mais je ne suis pas convaincu que protéger une partie du boot et un bout du système empêche une exploitation efficace de l'appareil. On peut toujours installer des programmes dans l'OS et modifier des configurations (exemple modifier le firewall d'un routeur), même si ce dernier point peut être repéré par l'utilisateur, en pratique ça risque souvent de passer inaperçu pour le grand public.
Il faut protéger contre toute modification en dehors du processus de mise à jour. Que celle-ci puisse par exemple ne se faire qu'au début du boot avant le démarrage du système, en vérifiant l'intégrité à ce moment-là, et qu'ensuite le système soit en lecture seule. Comme ça n'importe quelle faille ne pourra pas toucher au système, il faudrait une faille dans ce qui garantit la lecture seule. Les mises à jour sont téléchargées par l'OS dans une zone dédiée accessible en écriture, sans vérification d'intégrité nécessitant une clé secrète, puis l'appareil reboote pour faire la mise à jour, ce qui est déjà souvent fait comme ça dans l'embarqué.
Est-ce que la garantie de lecture seule est plus compliquée à implémenter qu'un secure boot ? Je ne sais pas, mais ça a le mérite de couvrir quasiment tous les cas, sachant que le tous absolu est impossible à atteindre.
Les configurations resteraient non protégées (qui parfois sont aussi composées de programmes pour les appareil où on peut installer des applications), mais pour elles je ne vois pas de solution.
Le 14 septembre à 19h30
Je ne suis pas d'accord avec toi sur ta conclusion. Oui, le ver mirai est clairement le scénario que le CRA cherche à éradiquer mais là où ton raisonnement est biaisé est qu'avant de mettre en place une attaque persistante, il faut rentrer. Le problème numéro un est donc ailleurs.
Un secure boot sur un appareil dont la sécurité est trouée comme les fromages suisses, cela ne sert à rien.
Il y a donc un travail nécessaire sur plusieurs plans:
....
Rien de tout cela n'est remplacé par le secure boot.
Je ne suis pas d'accord avec ton interprétation de l'annexe 1, §2.c:
« le cas échéant », ce n'est pas obligatoirement. Donc non, ce n'est pas une obligation de le mettre en place tout comme tu n'as pas à assumer le fait qu'un appareil client n'est pas à jour.
Par contre, la communication aux utilisateurs des mises à jour est bien une obligation.
Mon point de vue personnel est que OTA = cheval de troie. Je ne veux pas que quiconque modifie mes appareils sans mon autorisation. C'est une question de confiance et je ne fait pas confiance à n'importe qui.
Et non, c'est bien le CRA qui le garanti dans l'Annexe 1, partie 1, §2.m
Modifié le 13 septembre à 13h24
L'obligation numéro un est la mise à disposition de tes clients des informations: Tu dois avant tout communiquer à tes clients toutes les alertes, les versions concernées et les versions à installer pour corriger les failles. C'est en cela que tu permet aux correctifs d'être installé rapidement.
Il faut comparer cela aux messages de rappels sanitaires pour l'alimentaire par exemple.
En plus de cela, tu peux proposer à tes clients ou distributeurs d'être informés des mises à jour de sécu par mail ou RSS ou autre moyen de pousser l'information.
Tu dois en outre leur permettre de réaliser eux-même la mise à jour donc de télécharger tes firmware et les installer en local s'il ne s'agit pas d'appareils dont le fonctionnement dépend d'une infrastructure (box internet, passerelle domotique...).
Si une enceinte connectée n'est utilisable que connectée, les modifications opérables par le client ne peuvent se faire que en ligne et ses mises à jour sont en OTA car l'enceinte et son SI forment un tout.
Par ailleurs, le SI concerné est alors soumis au CRA lui aussi, ce qui implique que tu puisse accéder à toutes tes données, les récupérer dans un format exploitable et demander leur effacement complet.
Le 14 septembre à 17h42
Il y a des classes d'objets connectés pour laquelle la possibilité de modification par l'utilisateur rentre frontalement en conflit avec les exigences réglementaires & celles du constructeur: c'est les véhicules (même les trottinettes , les vélos, les twizzy... ...) - la volonté de l'utilisateur de modifier le firmware peux lui permettre de déroger aux obligations légales . Bien sur l'utilisateur engage sa propre responsabilité, mais je me demande si le constructeur ne serait pas aussi inquiété dans ce cadre pour avoir laissé cette possibilité (alors que sur les meules de notre enfance quand on montait un carbu polini , c'est pas le constructeur de la bécane qui était mis en cause...)
@white_tentacle :
Pour moi il y a une solution relativement "simple" au problème du secureboot: c'est de s'assurer que l'utilisateur fasse une action physique sur l'objet. Ça peux être un bouton physique, voire si les contraintes de production le permettent pas carrément une piste sur le circuit où déposer un point de soudure. Et dans ce cas, tu désactives la vérification de la clé du secureboot , et à l'annoncer à l'utilisateur avec un message (led , écran...) à l'utilisateur).
Si tu veux vraiment être sûr, tu peux même prévoir un fusible OTP qui fait que même en retirant le point de soudure le device ne retourne jamais en mode secureboot.
Le 14 septembre à 18h58
Il y a un monde entre la trottinette que tu cites, qui n'est connectée qu'à ton téléphone en bluetooth, et un routeur Internet même si, dans les deux cas, il s'agit d'embarqué et d'appareils reliés directement ou indirectement à un réseau.
Un appareil relié à un réseau n'est pas nécessairement destiné à être relié à Internet, ni en entrée, ni en sortie. Les risques liés à cette connexion ne sont donc pas les mêmes.
C'est tout l'enjeu de l'analyse de risque de prendre en compte le contexte d'utilisation prévu de l'appareil, dans les mesures de sécurisation.
Tu dois par contre explicitement interdire ou prendre en compte les mauvaises utilisations prévisibles de ton appareil comme par exemple, rendre disponible sur Internet, sans protection, un appareil destiné exclusivement à un usage local. Comme une Imprimante réseau par exemple.
Le 15 septembre à 08h31
@Inodemus Ce n’est pas ce que j’ai dit, et si j’ai donné l’impression que mon propos, c’est secure boot est la solution à tous vos problèmes, alors je me suis clairement mal exprimé. Par contre, je pense que secure boot est indispensable pour empêcher la persistence de la menace. Il y a pas mal de littérature là-dessus, et c’est quelque chose d’assez admis (tu peux regarder un peu les docs de qubes os, c’est très détaillé et didactique là-dessus), si dès le démarrage tu ne peux pas certifier que ce tu exécutes est correct, c’est mort pour la suite. Dans l’absolu c’est aussi vrai pour le hard, et dans certains cas l’analyse de risque va clairement écarter certains fournisseurs à cause de ça. Il y a probablement d’autres moyens d’y arriver (un peu comme ce que tu as décris, même si j’y vois déjà des limites), mais je pense qu’ils sont plus coûteux.
@OB c’est « simple » mais pas tant que ça. Ça veut dire dédier une entrée à ça, c’est con mais ça a un coût. Et si tu mets ça, lors de l’audit (ou même de l’auto-certification) ça te fait un élément en plus dont tu vas devoir prouver qu’il ne nuit pas à la sécurité de ton produit. S’il n’y a aucun retour commercial à en attendre, ni aucune obligation, ce n’est pas fait.
Le 15 septembre à 23h26
De mon côté, je vais devoir, et c'est aussi une obligation du CRA, ajouter une section cybersécurité dans les manuels utilisateurs afin d'expliquer comment il faut s'en servir, les bonnes pratiques à mettre en place et les choses qu'il ne faut pas faire.
Le fait que les produits de ma boîte ne se connectent pas à Internet par eux-même, peu importe la raison, est un gage de confiance pour les DSI qui ont complètement la main.
Modifié le 16 septembre à 07h07
D'ailleurs quelle est cette chose que vous mettez en plus du secure boot pour protéger ce qui se passe après ?
Le 16 septembre à 12h59
L’idée c’est qu’au pire, le jour où ton périphérique est corrompu en mémoire, tu fais on/off, ça redémarre en mode « propre » et ça télécharge la màj qui colmate la faille, et ton périphérique redevient non vérolé. L’attaquant peut essayer de t’empêcher de mettre à jour, mais ça commence à demander vraiment beaucoup d’efforts.
Le 15 septembre à 22h15
Modifié le 9 septembre à 17h46
Modifié le 10 septembre à 02h26
"ouin la télé m'espionne puisque j'ai laissé la reco vocale activée" <= ben oui, pourquoi, crois tu qu'elle va lire tes instructions par télépathie ?"
Pourtant, le réflexe numéro 1 sur une télé, c'est :
-soit de regarder la télé par appareil HDMI, donc la télé reste déconnectée du wifi
-soit de regarder la télé par TNT, pareil pas besoin de wifi
Dans tous les cas, je m'imagine pas une seule seconde "connecter à internet" par le wifi une télévision, tout court.
Soit elle peut regarder par la TNT, on regarde par la TNT, zéro internet/wifi nécessaire
soit on regarde par HDMI, et là pareil.
si une télé n'est pas capable d'afficher l'HDMI ou la TNT/rateau sans passer par internet/wifi, alors on la rend fissa au revendeur, et on lui fait sa réputation sur internet. Que je sache, la télé de LG fonctionne parfaitement en TNT/HDMI sans internet. Sauf retours différents?
Pour rappel, une télé doit rester dans son rôle que de consulter un signal qui vient de l'extérieur, càd du rateau, ou de l'appareil auquel on la branche.
Je pige meme pas qu'elles puissent gérer internet. Et si vous me dites "mais les applis" ... mais qui diable utilise une appli dans sa vie pratique? Ici android/iphone sont interdits à la maison.. (tout sur ordi, firefox/vlc ou rien)
Modifié le 10 septembre à 03h54
Le 10 septembre à 08h33
Sur ma Samsung, au premier allumage la tv propose de créer un compte et d'utiliser le smartphone pour régler les chaînes.
Pour contourner cela il faut brancher un clavier USB.
Ensuite, ma tv avait un bug sur la gestion des entrées. Obligé de la connecter pour mettre à jour le firmware.
Depuis:
Modifié le 10 septembre à 09h03
Et bah tu vas faire pas mal d'aller-retour, car toutes les TV sont connectés à présent. Et comme les constructeurs gagnent peu avec le matériel ils font tout pour passer des accord avec Netflix / Amazon (d’où les boutons sur la télécommande, les "alexa intégré") .... quand c'est pas carrément eux même chercher à récupérer des données perso.
Ils sont d'ailleurs pas mal en concurrence avec les box tv de nos opérateurs, qu'ils aimeraient bien remplacer pour vendre eux-même les données de conso.
Sinon faut acheter un écran d'ordi (même si comme le dit l'article, LG , toujours dans les bons coups a aussi merdé de ce coté là). Et tu verras que pour la taille c'est pas trop le même prix (mais là par contre , ya une entrée HDMI & c'est tout)
Les pirouettes décrites par Wosgien pour juste faire marcher ta propre TV sont insupportable, mais pourtant systématiques sur le matos récent quelque soit la marque.
Les seuls où j'ai vu un truc sans fioriture qui marchent ne sont pas vendu au grand public, ce sont des TV spécifiques pour les hôtels ou les lieux public, avec des capacité de personnalisation assez dingue (logos, plans de chaines, ...). C'est les mêmes marques que tu as à Darty ..... mais un firmware différent (ce qui nous ramène à la discussion avec white_tentacule)
La dégradation de la TNT est assez nettes à certains endroit - il y a moins d'intérêt à maintenir l'infra maintenant que 90% des gens peuvent utiliser la fibre pour ce service.
(Et on est sur du grand public donc les 10% qui sont en galère n'existent tout simplement pas pour eux). J'ai jamais installé plus de de paraboles + décodeurs TNTSat / Fransat chez des vieux que depuis 5 ans.
Le 10 septembre à 13h24
J'y crois pas une seule seconde, ils perdraient tous leurs clients.
Pour info, dans deux contextes que je croise tous les mois :
-résidence secondaire sans connexion internet
-télé dédiée à une console de jeux, sans wifi à portée (ps2, ps3, retrogaming)
ces deux contextes là imposent qu'une télé fonctionne sans aucune connexion internet.
Une télé exigeant une connexion internet, est une télé à rendre et dont le fabricant doit être boycotté. Si aucun n'est capable d'en vendre une classique, alors aucune télé ne sera achetée, on se dirigera vers un écran d'ordi, ou un vidéoproj que le client controle, comme viennent de le faire mes nouveaux voisins.
Modifié le 10 septembre à 16h03
(après je pense que c'est possible, même si je pense que la TV va vite te saouler pour qu'elle s'y reconnecte).
J'ai un des premier écran 4K JVC , il y a une prise ethernet (pas de wifi) mais sans utilité.
Les premiers écrans samsung aussi.
Mais achète une TV aujourd'hui ? Entre les AndroidTV , les TitanOS, LG-OS, ... ?
(Après c'est cool ca fait du business pour la réparation de vieux postes remarque)
Je reste d'accord avec toi sur le fond, je déplore cette situation.
Modifié le 10 septembre à 09h20
edit: je viens de réaliser que tu parlais ici du contexte LG avec une communication vers LG de données au travers de l'accès réseau. Donc ce que j'ai posé ne s'applique pas. Tu as raison isolé la TV avec sa prise HDMI reste le moyen le plus simple d'éviter ce gente de situation.
Le 10 septembre à 09h42
Est-ce que tu n'as pas l'impression que tu déportes le problème.
Le 10 septembre à 09h53
Le 13 septembre à 08h37
Le 14 septembre à 08h17
Le 10 septembre à 13h22
Modifié le 10 septembre à 16h46
naaaa je rigole.
J'ai une shield TV pro, ça n'a pas l'air de beaucoup discuter avec l'extérieur si j'en crois les requêtes DNS qui passent. après j'ai pas mis de wireshark au milieu, donc je ne saurais dire.
Le 10 septembre à 23h11
A part Chromecast (non..), Apple TV (non aussi), il me semble qu'il n'y a pas beaucoup de solution si on souhaite ne pas utiliser le player d'une box de FAI (ou la partie smart de la TV)?
Merci
Le 12 septembre à 07h45
Le 12 septembre à 13h02
Ensuite, sur le plan perf, celle que j'avais testé était un peu faible sur des flux UHD, chose que je n'ai pas rencontré avec d'autres hdw mais qui avaient d'autres défauts (ie: support DRM Widevine L1).
C'est quand même la jungle avec des spécs qui semblent différentes entre diffuseur (cela ne s'arrte pas au codec supporté) et des appareils qui ne sont parfois peu ou pas compatible.
A priori la Shield Pro coche beaucoup de case (sauf le support des codecs récents et p-e son age) avec une base utilisateur considérables sur toute la planète.
Le 13 septembre à 08h13
J'ai choisi ce truc car "supporté" par Google, UI décente. Je n'utilise pas d'UHD (j'ai la version qui doit décoder la AV1 en hardware, mais ne fait pas d'UHD). Et parce qu'ils coûtaient 30 €.
Leur conso en marche est entre 2 et 5W, en veille environ 0.5.
Sinon c'était Linux, avec un browser pour un peu tout. Mais un pi consomme plus et ne se met pas en veille, et une machine qui se mette en veille pour le moment coûte beaucoup plus cher (par exemple des trucs de chez Hard Kernel).
Je suis preneur de toute alternative.
Le 13 septembre à 21h26
Le 17 septembre à 00h42
UHD je fais pas j'ai une vieille FHD, et multicast IPV6 non plus.
Bon ça doit se faire, mais ça dépend surtout des perfs du stockage à mon avis.
Jsuis un peu limité par les perfs des disques de ma Delta j'ai l'impression, mais pour mon usage ça passe très bien.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?