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 Eric P. . En réponse au journal Une backdoor dans les ESP32 ?. Évalué à 6. 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.