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 pulkomandy (site web personnel, Mastodon) . En réponse au journal Une backdoor dans les ESP32 ?. Évalué à 8.
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é.