À titre perso j'aime bien bidouiller l'ESP32. OK ce n'est pas du hardware libre mais ça s'utilise assez facilement, on trouve facilement de la doc en ligne, des exemples, etc. Bref j'aime bien.
Mais c'est vrai que ce n'est pas libre. Et pas complètement documenté apparemment :
Même s'il m'étonnerait beaucoup que les chinois s'intéressent à mes quelques bricolages, par principe ça me dérange (« nothing to hide » bin si comme tout le monde) et surtout, savez-vous si cette puce est utilisée sur des appareils vraiment sensibles ?
# un avis contraire
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+12/-0).
The ESP32 "backdoor" that wasn't
https://darkmentor.com/blog/esp32_non-backdoor/
[^] # Re: un avis contraire
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+4/-5).
C'est quand même probablement une backdoor ou une partie… mais ce n'est pas prouvé. Ce sont des fonctions non documentées qui ne peuvent avoir qu’un intérêt peu avouable.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: un avis contraire
Posté par gUI (Mastodon) . Évalué à 7 (+4/-0). Dernière modification le 09 mars 2025 à 16:47.
Ça c'est ton avis.
En attendant les auteurs de l'article original ont changé leur titre en parlant maintenant de "undocumented commands" à la place de "undocumented backdoor".
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: un avis contraire
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+6/-7).
Non mon avis c'est que c'est forcément pas pour du joli. Si ce n'est pas une backdoor c'est pour en permettre, ou pour autres chose du même style.
Depuis quand on met des fonctionnalités dans un outils sans les vendre? Surtout dans les processeurs, ça coûte cher à développer et en consommation, ça prends une place chère…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: un avis contraire
Posté par mahikeulbody . Évalué à 6 (+4/-0). Dernière modification le 09 mars 2025 à 19:35.
D'après l'article cité par Benoît Sibaud, ce ne serait pas spécifique à ESP. Donc quelle que soit le nom qu'on donne à ça, il ne semble donc pas fair de parler de ça en pointant du doigt ESP alors que c'est pareil chez Broadcom et les autres fabricants de modules Bluetooth. Ce qui n'empêche pas d'en parler, bien au contraire.
[^] # Re: un avis contraire
Posté par Maclag . Évalué à 10 (+9/-0).
Ou ça servait juste à déboguer la puce et/ou ses pilotes pendant la conception.
[^] # Re: un avis contraire
Posté par ChocolatineFlying . Évalué à 2 (+2/-1).
j'y crois plus dans ce sens, au vue des pb de stabilité que je vois sur internet et même sur leur forum. Je parle pas de mon cas qui doit être particulier et mon code aussi bourrée de backdoor que leur puce :)
[^] # Re: un avis contraire
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
Dans ce cas ESP ne devrait pas tarder à le dire et l’expliquer… et même à le documenter… et cela sera vérifié.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: un avis contraire
Posté par pasBill pasGates . Évalué à 6 (+6/-1).
Ca fait juste des decennies que les constructeurs et éditeurs le font. Bienvenue dans le monde de l'électronique et informatique.
[^] # Re: un avis contraire
Posté par 2PetitsVerres . Évalué à 6 (+4/-0).
Difficile à dire précisément, mais j'imagine que "longtemps" est une réponse suffisamment précise. Par exemple, ici on peut voir qu'une petite boîte californienne qui vendait des mcu/cpu pas très importants il y a 40/50ans embarquait des instructions non documentées.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: un avis contraire
Posté par aiolos . Évalué à 4 (+2/-0).
En électronique grand publique, en particulier dans les SoCs, il est très courant que le même circuit soit présent dans tous produits de la même famille, avec des zones différentes activées en fonction de la gamme. Par exemple, des caméras avec les capacités de 4K activées ou non selon le prix final de l’appareil, mais biens présentes sur le circuit vendu.
[^] # Re: un avis contraire
Posté par cévhé . Évalué à 6 (+5/-0).
Peut-être simplement parce qu'une backdoor n'est généralement pas documentée. Pas publiquement au moins.
[^] # Re: un avis contraire
Posté par 2PetitsVerres . Évalué à 2 (+0/-0).
Clairement, qui oserait avouer qu'il teste son matériel avant de le vendre !
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: un avis contraire
Posté par cg . Évalué à 10 (+9/-1).
En résumé, l'intention importe peu : si des commandes "cachées" permettent d'abuser des fonctions prévues par le composant, alors elles seront découvertes et seront abusées.
Ce genre de commande pourraient être neutralisées par un fusible interne après les phases de test de qualité du composant.
[^] # Re: un avis contraire
Posté par Misc (site web personnel) . Évalué à 2 (+0/-1).
Pourquoi tu veux faire retirer des fonctionnalités du matos que j'ai payé et qui m'appartient ?
[^] # Re: un avis contraire
Posté par nud . Évalué à 10 (+12/-0).
Quand j'ai vu la news pour la première fois, vu la formulation, j'ai pensé que par backdoor ils entendaient qu'on pouvait prendre le contrôle d'un ESP32 via bluetooth. Mais en fait il s'agit de commandes qui peuvent être utilisées par le logiciel installé sur l'ESP32. C'est tout de suite moins effrayant (tendance inutile) dans le cas classique rencontré par les hobbyistes ou même pour la plupart des objets connectés.
Comme l'indique le lien posté par Oumph<, ce type d'API non documentées et potentiellement abusables est présent chez presque tous les constructeurs parce que ça a de l'intérêt lors des phases de validation/test/programmation. Mais bien que ça pourrait être utilisé pour gagner des privilèges, ça implique d'avoir différents niveaux de privilège, ce qui est quand même très rare dans des projets embarqués.
Bref, y voir de mauvaises intentions est un peu prématuré.
[^] # Re: un avis contraire
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+6/-2). Dernière modification le 10 mars 2025 à 17:14.
Bonnes ou mauvaises intentions, qu'est-ce que ça permets comme attaques réalistes? Ouvrir la porte de mon garage ? C'est là ou Mme Newton entasse des affaires inutiles et encombrantes, ce serait vraiment pas de bol si un hacker à capuche en profitait pour tout voler (et en plus pas de bol, ma carte de déchetterie est aussi à base d'ESP32).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: un avis contraire
Posté par MicP . Évalué à 3 (+2/-0).
Bonjour
https://circuitdigest.com/news/the-truth-behind-alleged-backdoor-in-esp32-bluetooth-stack
traduction :
Donc, il n'y a que l'ESP32 qui serait concerné.
Ça ne concerne PAS les ESP-C2 ESP-C3 ESP-C5 ESP-C6 ESP-C61 ESP-S2 ESP-S3 ESP-H4 (et peut-être aussi l'ESP-P4)
[^] # Re: un avis contraire
Posté par MicP . Évalué à 2 (+1/-0). Dernière modification le 27 mars 2025 à 06:28.
Un document à ce sujet,
de Mahavir Jain (Senior Manager @ Espressif Systems) :
ESP32 Undocumented Bluetooth Commands: Clearing the Air
[^] # Re: un avis contraire
Posté par MicP . Évalué à 1 (+0/-0).
Zut, le lien avait déjà été posté plus bas.
Désolé => vous pouvez supprimer ce message et mon précédent.
Merci.
# Quasiment opensource
Posté par David Demelier (site web personnel) . Évalué à 10 (+10/-0).
Pas entièrement mais ça fait parti des hardware les plus libres. Leur HAL est libre, leur outils (idf) le sont, ils poussent du code dans le projet zephyr. Bref, Espressif est vraiment coopératif.
Pour le moment ce n'est pas le cas de la parti radio (wifi/bt) comme pour beaucoup de chip (j'ai vraiment jamais compris cette obsession…) mais le reste l'est déjà beaucoup
Vive ESP32 et vive RISC-V.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quasiment opensource
Posté par karteum59 . Évalué à 10 (+12/-0). Dernière modification le 11 mars 2025 à 07:00.
Je vois au moins deux raisons possibles
Les devs Linux ont à mon avis trouvé un compromis plutôt bon entre quelque chose d'ouvert mais néanmoins de raisonnablement contraint (pour le peu que j'ai regardé, il me semble que le système CRDA/regdb est suffisamment bien fait pour qu'il soit difficile de sortir des clous involontairement). Mais c'est un sujet récurrent chez les régulateurs que d'imposer un hardware/firmware verrouillé pour ne pas laisser l'usager faire n'importe quoi avec la radio.
(pour donner un exemple : les radars météo sont aujourd'hui fréquemment brouillés par des AP wifi 5 GHz, au point que nombre d'entre eux sont désormais contraints de changer de bande - aux frais de Météo France qui ne roule pourtant pas sur l'or - alors que ce sont eux les usagers primaires. Le DFS était sensé les protéger, mais entre les mauvaises implémentations et les usagers qui bidouillent pour le désactiver parce que "ça rend le wifi plus instable" la bande est désormais pourrie pour les radars… Et je rappelle que la météo ce n'est pas juste les 5 minutes à la TV pour te dire s'il fera beau demain, mais c'est aussi la sécurité aéronautique et maritime)
[^] # Re: Quasiment opensource
Posté par bertrand . Évalué à 4 (+3/-0).
Quand j'ai fait mon service militaire, dans un millénaire précédent, j'ai vu l'armée de l'air débarquer un jour.
En discutant avec ceux qui savent, j'ai appris qu'ils venaient grosso modo une fois par an poser leur équipement là, sur ce point haut dominant la métropole, pour repérer tous les émetteurs sur les bandes de fréquence réservées pour l'armée de l'air. Et que dés qu'ils en repéraient un, ils basculaient en émission pour griller le récepteur associé avec quelques kilowatt extrêmement bien focalisé.
[^] # Re: Quasiment opensource
Posté par cg . Évalué à 2 (+0/-0).
Je ne m'étais jamais dit que la certification concernait aussi le firmware, c'est un très bon argument. Merci !
# Réponse d’espressif
Posté par cévhé . Évalué à 6 (+5/-0).
Espressif a répondu :
https://www.espressif.com/en/news/Response_ESP32_Bluetooth
Même remarque qu’initialement : je n’ai aucune compétence pour juger de la qualité de cette réponse mais je lirai avec plaisir vos commentaires
[^] # Re: Réponse d’espressif
Posté par cg . Évalué à 4 (+4/-2).
Déjà c'est super chouette que Espressif fasse une réponse. Cette réponse se veut rassurante, et est l'est partiellement.
Toutefois elle confirme que ces commandes devraient être désactivées au moment du passage en production :
Peut-être que ce sera fait via un fusible matériel dans de futures puces ?
Mais aussi :
Et là, ça en dit long sur l'état de l'Internet des objets :-/ … Laisser disponible des commandes permettant de contourner des niveaux de sécurité est donc courant… mais est-ce souhaitable pour autant ?
[^] # Re: Réponse d’espressif
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+6/-0).
Je ne comprend pas de quoi tu parles quand il s'agit de "contourner des niveaux de sécurité"?
On parle de commandes de debug qui permettent au logicieltournant sur la puce de manipuler le composant bluetooth présent également sur la puce.
Si le code n'utilisepas ces commandes (ce qui est probable, puisqu'elles ne sont pas documentées), il ne se passe rien.
Espressif utilisent probablement ces commandes dans leurs développements internes et ça pourrait être pratique de les avoir sous la main hour déployer un patch depuis un driver, un jour.
Dans le cadre d'un scénario d'attaque: pour exploiter ces commundes, il faut déjà être en mesure d'exécuter du code sur la puce. D'où le fait que ça ne soit pas vraiment une backdoor, ça en serait une si on pouvait accéder à ces commandes directement depuis le bluetooth par exemple et dire à la puce "hey donne moi un dump de ton firmware qui est censé être protégé"
Maintenant, dans le cadre d'une attaque sur du matériel utilisant un ESP32, ces commandes pourraient être utilisées pour faire une "escalation de privilèges" comme on dit: une fois que l'attaquant a réussi à exécuter du code pouvant communiquer avec le composant bluetooth, il pourrait trouver un moyen d'exploiter ces commandes pour, peut-être, réussir à injecter du code quelque part (dans le noyau? Dans le firmware bluetooth?) Et ainsi gagner des permissions supplémentaires. Mais ça, c'est le cas de n'importe quel bout de logiciel.
La chose un peu dommage, c'est que ça ne soit pas documenté. Quelqu'un qui aurait tenté de sécuriser par tous les moyens son matériel, pourrait donc être surpris de découvrir ce possible vecteur d'attaque auquel il n'aurait pas pensé.
[^] # Re: Réponse d’espressif
Posté par octane . Évalué à 8 (+6/-0).
Ce sont des commandes hci, non? Donc avoir déjà un gros niveau de privlèges sur l'hôte qui communique avec la puce BT.
Il utiliserait ces commandes pour analyser le firmware et trouver une vuln dans le firmware de la puce BT. Ce sont des commandes de DEBUG, donc depuis un hôte privilégié (genre faut être root quoi), tu va pouvoir accéder à des infos sur le chip BT.
Avec une chance absolument énorme (et beaucoup de travail), il trouverait une vuln qui permettrait, en envoyant des trames BT, de prendre le contrôle de la puce BT (et ça j'y crois pas trop). Et ensuite, ben il est root d'un chip wifi, et il va falloir basculer depuis le chip wifi sur l'hôte pour obtenir un truc intéressant. Bref, en tant qu'attaquant tu passes de trois fois rien à pas grand chose.
Si ça intéresse des gens, je ne peux que les inviter à lire https://github.com/seemoo-lab/internalblue c'est super bien expliqué.
[^] # Re: Réponse d’espressif
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4 (+3/-0).
Des commandes de debug c'est généralement pour tester des fonctions sans passer par toutes la pile habituelle et voir le résultat facilement. On imagine bien que ça peut souvent avoir des conséquences sur la sécurité.
D'ailleurs combien de failles de sécurité software sont dû à un mode debug, des valeurs par défaut, un jeu de test, le détournement d'une fonctionnalité un peu moins connue…?
Bref le hardware ne fait pas exception. S’il y a une faille à chercher pour un hacher, c'est bien là.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Réponse d’espressif
Posté par octane . Évalué à 3 (+1/-0).
Nan, faut vraiment voir ça comme un gdb. Je fais un parallèle: c'est comme si là, les chercheurs découvrent qu'un linux embarque un gdb dans leut distribution. Et ils disent y'a une backdoor, parcequ'avec gdb, on peut modifier des registres CPU, lire la mémoire des programmes, l'écrire etc..
[^] # Re: Réponse d’espressif
Posté par cg . Évalué à 3 (+1/-0).
Ton parallèle est vraiment bien trouvé. C'est un peu comme si tu avais mis en place des couches d'abstraction et un MAC, et que d'un coup, tu découvres qu'un gbd dans un container Docker permet de lire et d'écrire dans la RAM du kernel hôte tout en contournant tranquillement SELinux.
Bien sûr, dans le cas de ces puces, il s'agit de couches bien plus simples, pour lesquelles les couches d'abstractions sont rarement respectées, donc dans beaucoup de cas, ça ne change rien.
Ce qui me chagrine, c'est qu'il semble que ce soit l'état de l'art dans ce genre de composant ("nan mais tout le monde le fait"), et je me permet de trouver ça un peu moisi :).
[^] # Re: Réponse d’espressif
Posté par octane . Évalué à 4 (+2/-0).
Alors non. Et c'est pour ça que l'histoire a fait un flop. le gdb que tu as trouvé dans ton docker permet d'écrire dans la mémoire de ton docker et c'est tout.
Faut vraiment voir la puce bluetooth comme un ordinateur à part entière (c'est souvent un CPU ARM) avec de la RAM, une unité de stockage et un bus de communication.
Ce qu'ils ont trouvé, c'est uniquement dans la puce bluetooth. Jamais ils ont dit que tu peux pirater l'hôte.
Osons un autre parallèle, c'est comme si tu disais: j'ai un gdb sur un firefox, est-ce que ça veut dire que je peux pirater le serveur apache? Ca parait osé quand même.
[^] # Re: Réponse d’espressif
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+1/-1).
Alors, ce n'est pas tout a fait ça. Car là, la puce est accessible par du code. C'est comme si tu disposait d'un terminal sur ton Linux sur un shell restreint… et que tu découvre, qu'il y a d'autres programmes non documentés accessibles… et que ces programmes sont des valgrind/gdb…
Et d'une ces programmes vont peut-être te permettre de trouver des failles, soit dans ces programmes moins "durcis" soit dans les autres à l'aide de cet outils…
Mais surtout, on peut se demander si l'admin, n'a pas laissé ces programmes parce qu' intrinsèquement, ils contiennent une backdoor pour accéder à ton terminal sans le login/mdp…
C'est jamais bon signe une telle découverte. Je pense qu'il y a sur ces puces des backdoor, et que c'est un ordre de la NSA… Alors je vois un intérêt à creuser.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Réponse d’espressif
Posté par octane . Évalué à 4 (+2/-0).
gné? As tu juste compris qu'il s'agit de deux systèmes indépendants? C'est vraiment comme si tu as 2 PC côte à côte.
J'arrête ici, mais tout est documenté, il y a eu de la recherche, tu peux même download un firmware de puce bluetooth et l'analyser dans son entiereté. Donc en vrai, arrête de te demander, analyse le firmware, trouve une backdoor et annonce le au monde! Puisque tu es persuadé que ça cache un truc, tu as tout ce qu'il faut pour le prouver, en avant!
[^] # Re: Réponse d’espressif
Posté par cg . Évalué à 3 (+2/-1).
Je me base sur l'analyse dans l'article de "dark mentor" mentionné par Benoît. Il y est expliqué entre autres que ça affaibli les fonctions comme Secureboot, par exemple.
Attendons quelques semaines pour voir si une attaque sympa voit le jour :).
[^] # Re: Réponse d’espressif
Posté par octane . Évalué à 3 (+1/-0).
Si je ne m'abuse, c'est le secureboot du chip, hein, pas de ton ordinateur. Donc éventuellement, ton chip bluetooth peut voir sa chaine de boot pétée, et démarrer un firmware arbitraire.
Firmware qui lui donne le droit d'envoyer des trames bluetooth mal branlées vers d'autres puces bluetooth, ou remonter des infos mal fichues vers ton hôte. Si ton hôte (ton kernel linux donc) est pas trop mal fichu, il va gérer ces situations très bien en droppant ces infos. Imagine une carte réseau qui remonte des trames n'importe comment, ton kernel va drop les trames et c'est tout.
[^] # Re: Réponse d’espressif
Posté par Eric P. . Évalué à 6 (+5/-0). Dernière modification le 18 mars 2025 à 13:34.
Juste pour clarifier: l'hote d'un chip ESP32 ce n'est pas "ton kernel Linux", c'est habituellement l'OS principal d'un objet IoT comme le distributeur de croquettes connecte pour ton chat, un smartlock etc.
L'ESP32 peut etre utilise:
- de facon completement autonome, c'est a dire que c'est le chip principal de l'objet IoT (les gens qui font de la domotique l'utilisent beaucoup comme ca pour des capteurs ou actionneurs, avec leur programme dans la RAM de l'ESP)
- ou juste pour gerer la partie Bluetooth/Wifi, et en cas la ROM de l'ESP va exposer une interface (la fameuse HCI) pour qu'un autre microcontrolleur dans l'objet IoT puisse controller le Bluetooth.
Ici, en l'occurence, grace a ces fonctions non-documentees dans l'interface, l'objet IoT pourrait lancer des attaques bluetooth. Donc le risque serait si l'objet IoT lui-meme est compromis, l'attaque pourrait se propager au chip ESP32 et faire des choses louches au niveau des trames Bluetooth.
Note que c'est un peu dommage que pour une fois qu'un constructeur de microcontrolleur publie le code de la ROM, il se prenne un bad buzz et est accuse de backdoor, alors que ces fonctions non-documentees sont autorisees par le protocol HCI et apparemment relativement frequentes sur les chips Bluetooth (bien que faibles cote securite, et qui auraient du etre retirees en effet).
Que l'objet IoT ait acces complet a sa propre puce Wifi/Bluetooth, ca peut meme sembler logique.
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: Réponse d’espressif
Posté par cg . Évalué à 3 (+1/-0).
D'ailleurs, c'est hyper bien expliqué dans cette article du blog technique d'Espressif : ESP32 Undocumented Bluetooth Commands: Clearing the Air.
Les choses sont posées à plat, mais, désolé, je peine à être convaincu par les arguments, qui sont :
Bref, j'aurai préféré une réponse comme "déso, on aurait du désactiver ces commandes de debug juste après les contrôles qualité en sortie de chaîne de fabrication, voici un correctif".
[^] # Re: Réponse d’espressif
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0).
c'est pas facile un correctif dans du silicium ;)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Réponse d’espressif
Posté par cg . Évalué à 2 (+0/-0).
Pourtant: "Espressif will provide a fix that removes access to these HCI debug commands through a software patch for currently supported ESP-IDF versions".
[^] # Re: Réponse d’espressif
Posté par Benjamin Henrion (site web personnel) . Évalué à 2 (+3/-2).
J'aurais préféré une réponse du style "on va arrêter de faire des blob binaires pour la radio".
Mangez des blobs binaires, c'est bon pour la santé et la sécurité.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.