Votre question peut être lue de deux manières, DarkCoffee:

Si un appareil basé sur Arduino peut être amené à déborder de sa pile, peut-il être exploité?

Oui, c'est possible d'exploiter un débordement de pile sur un Arduino.

Une attaque possible est la méthode de programmation orientée retour, qui nécessite un firmware suffisamment complexe. Donc, une défense ici est de garder votre firmware aussi simple que possible. Il est hautement improbable que le croquis "Hello world" d'Arduino soit vulnérable. Cela ne devrait pas vous être très réconfortant, car un clignotant LED n'est pas terriblement utile . Un firmware utile aura plus de fonctions, et donc plus de queues de fonctions à récolter pour une utilisation dans une machine abstraite.

L'Arduino possède également un chargeur de démarrage, qui a intrinsèquement le pouvoir d'écraser le firmware. Il est peut-être possible de l'exploiter pour écraser un firmware existant bénin mais vulnérable avec un firmware malveillant.

Ma lecture de la première page de le document d'attaque de l'INRIA me porte à croire qu'il combine les deux approches: programmation orientée retour pour exécuter suffisamment de code pour activer la capacité d'auto-clignotement du microcontrôleur afin que le code arbitraire puisse être chargé en permanence.

Y a-t-il des attaques par débordement de pile sur les Arduinos en général?

Je n'ai connaissance d'aucune attaque qui fonctionne sur tous les appareils basés sur Arduino. Encore une fois, l'esquisse du clignotant LED "hello world" est probablement invulnérable, simplement parce qu'elle est trop triviale pour être vulnérable.

Plus vous écrivez de code, plus il est probable que vous créiez une vulnérabilité.

Notez qu'écrire 5 000 lignes de code puis remplacer 2 kLOC par 1 000 nouvelles lignes n'est pas une économie nette de 1 kLOC du point de vue de la sécurité. Si ces 5 kLOC étaient sécurisés et que vous vous êtes trompé lors de l'écriture de certains des nouveaux 1 kLOC, c'est toujours une vulnérabilité. La morale de l'histoire est que le code le plus sécurisé a tendance à être celui qui est regardé le plus longtemps, ce qui signifie le garder inchangé le plus longtemps possible.

De toute évidence, chaque vulnérabilité doit être corrigée dès que possible. Ce n'est pas un argument pour conserver les anciennes vulnérabilités. C'est un argument contre l'ajout irréfléchi de fonctionnalités à un code que vous croyez sûr grâce à l'inspection, l'audit et l'analyse.

L'important est que nous ne pouvons pas répondre à cette question par «non» avec quelque chose de proche de la certitude absolue, à moins de vérifier formellement un système Arduino donné, tel que déployé, instruction par instruction, et même alors.

Les Arduinos ont des interfaces Ethernet en option et d'autres formes de communication à distance, de sorte que les exploits à distance sont possibles dans le concept. Il existe une pile TCP pour l'interréseau, et même si elle est petite et simple, elle pourrait avoir des défauts.

Mais, spécifiquement, les débordements de tampon de pile sont-ils possibles? Considérez que l'Atmel Les processeurs AVR ont une architecture Harvard, ce qui signifie que le code et les données résident dans des espaces mémoire séparés . Cela tend à exclure les exploits où le code est injecté dans la pile puis exécuté. Une adresse placée dans la pile par un vecteur d'attaque sera interprétée comme étant dans l'espace de code, tandis que les octets de vecteur d'attaque restants contenant la charge utile malveillante sont dans l'espace de données.

Si vous regardez ce qui est normalement exploité dans les systèmes x86, c'est-à-dire les débordements de tas, les débordements de pile, les écrasements SEH, les chaînes de format, etc., il n'y a pas une telle surface d'attaque. À l'exception peut-être des chaînes de format, je ne vois aucune de ces attaques fonctionner car l'architecture ne le permet tout simplement pas.

Si vous êtes intéressé par ce type de recherche, je vous recommande de regarder l'horloge et les pépins de tension, cela permet souvent d'extraire des informations des appareils même lorsqu'ils sont verrouillés, et de simplement les déranger en général. Vous pouvez également essayer une analyse de puissance différentielle si vous êtes à la hauteur des statistiques. Enfin, les attaques chronométrées sont probablement les plus faciles à exploiter si vous cherchez quelque chose pour commencer.

Du côté matériel, il y a un programme appelé degate qui permet d'inverser les puces au niveau du silicium. Il y a eu quelques conférences décentes sur le sujet et vous allez probablement les adorer.

Il n'y a vraiment rien à exploiter sur un processeur embarqué comme l'ATmega (utilisé sur Arduino) car il n'y a qu'un seul niveau d'exécution (accès complet) et pas de trucs fantaisistes comme l'anneau de processeur Intel / AMD protection (en gardant le code utilisateur à l'écart du code du noyau dans le matériel).

Si vous connectez un débogueur, vous obtenez un accès complet à la RAM et au flash, il n'est donc pas nécessaire d'exploiter quoi que ce soit, vraiment ...

Les exploits de tampon avec l'intention de contrôler via l'incection de code ne fonctionnent que contre Princeton Architecture, car le stockage des données et le stockage des programmes partagent la même mémoire.

Maintenant, notre petit Atmel courageux a une architecture Harvard - il exécute du code à partir d'une mémoire différente de celle des données. Et notre débordement de tampon mal exploité ne peut écrire que dans la SRAM, ce qui ne peut pas être exécuté.

Cela pourrait faire planter l'Arduino, cependant, si vous avez un moyen de transférer des données vers le tampon.

Comme l'a souligné Madmanguruman, il n'y a vraiment rien à exploiter sur un processeur embarqué, d'une certaine manière. La vraie question est: POURQUOI voulez-vous exploiter un appareil embarqué? Si vous aviez un Ardunio autonome et que vous pouviez exploiter quelque chose, que pourriez-vous en faire?

Dans les PC modernes, le plus souvent l'exploitation d'une vulnérabilité vous donnera un accès root à distance, ce qui est à peu près l'objectif ultime. Mais un système embarqué n'a généralement pas de fichiers, d'informations ou quoi que ce soit de ce genre, bien qu'il y ait des exceptions.

Si vous voulez exploiter un système embarqué, c'est généralement dans un but précis. En plus de cela, l'exploit sera complètement unique presque à chaque fois. De plus, la plupart des périphériques embarqués ne seront pas connectés; ce qui signifie que vous avez besoin d'un accès physique à eux pour faire quoi que ce soit. Et une fois que vous avez un accès physique, vous détenez toutes les cartes et tout peut être fait. C'est l'un des rares aspects de l'ingénierie à essayer de trouver une solution à un problème, et non l'inverse.