Comment les tests fuzz renforcent la sécurité des appareils IoT

Les tests Fuzz représentent un moyen important à la disposition des ingénieurs pour trouver des faiblesses dans les appareils et doivent être pris en compte pour renforcer les interfaces des appareils IoT.

La prolifération des appareils IoT s'accompagne d'une augmentation des attaques de sécurité intégrées. Historiquement, les ingénieurs de systèmes embarqués ont ignoré la sécurité de la couche périphérique malgré les nombreux domaines des périphériques embarqués qui sont vulnérables aux bogues. Les ports série, les interfaces radio et même les interfaces de programmation/débogage peuvent tous être exploités par des pirates. Les tests Fuzz représentent un moyen important à la disposition des ingénieurs pour trouver les faiblesses des appareils embarqués, et devraient être pris en compte pour renforcer les interfaces des appareils IoT.

Qu'est-ce que le test fuzz ?

Les tests Fuzz, c'est comme le million de singes mythiques qui tapent au hasard pour écrire Shakespeare. En pratique, les œuvres de fiction nécessitent de nombreuses combinaisons aléatoires pour produire une phrase simple, mais pour les systèmes embarqués, nous avons juste besoin de changer quelques lettres d'une bonne phrase connue.

De nombreux outils commerciaux et open source sont disponibles pour mettre en œuvre des attaques fuzz. Ces outils génèrent des chaînes d'octets aléatoires, également appelés vecteurs flous ou vecteurs d'attaque, et les soumettent à l'interface testée, en gardant une trace du comportement résultant qui pourrait signifier un bogue.

Le test Fuzz est un jeu de nombres, mais nous ne pouvons pas essayer un nombre infini d'entrées possibles. Au lieu de cela, nous nous concentrons sur l'optimisation du temps de test en maximisant le taux de soumission de vecteurs fuzz, l'efficacité des vecteurs fuzz et les algorithmes de détection de bogues.

Concepts de test Fuzz

Étant donné que de nombreux outils de test fuzz ont été conçus pour tester les applications PC, il est plus facile de les adapter si vous exécutez votre code intégré en tant qu'application PC compilée nativement. L'exécution de code intégré sur un PC offre un énorme avantage en termes de performances, mais présente deux inconvénients. Premièrement, les microprocesseurs PC ne réagissent pas de la même manière que les microcontrôleurs embarqués. Deuxièmement, nous devons réécrire tout code qui touche le matériel. Cependant, dans la pratique, les avantages de fonctionner sur un PC l'emportent sur les inconvénients. La vraie barrière est la difficulté de porter du code à compiler nativement sur le PC.

Comment savons-nous quand un vecteur fuzz déclenche un bug ? Un crash est facile à repérer, mais il est plus difficile d'identifier les vecteurs de fuzz qui provoquent une réinitialisation. Les bogues de dépassement de mémoire ou les écritures de pointeurs parasites - le type de bogues les plus précieux pour les pirates - sont presque impossibles à discerner de l'extérieur du système car ils n'entraînent généralement pas de plantage ou de réinitialisation.

De nombreux compilateurs modernes, tels que GCC et Clang, ont une fonctionnalité appelée nettoyage de la mémoire. Cela marque les blocs de mémoire comme propres ou sales, selon qu'ils sont en cours d'utilisation, et signale toute tentative d'accès à la mémoire sale. Cependant, l'assainissement de la mémoire consomme des cycles de flash, de RAM et de processeur, ce qui rend difficile l'exécution sur les appareils intégrés. Ainsi, à la place, nous pouvons tester un sous-ensemble de code, créer une version de l'appareil avec plus de ressources ou utiliser un PC.

L'efficacité d'un test peut être évaluée par la quantité de code exercé. Ici aussi, les compilateurs peuvent suivre l'utilisation de la mémoire en utilisant des appels de sous-programme de chapelure. La bibliothèque de couverture de code maintient une table de valeurs d'utilisation pour chaque chemin de code, en les incrémentant lorsque le fil d'Ariane s'exécute.

Cependant, les nombres de couverture de code sont difficiles à interpréter pour les tests de fuzz intégrés car une grande partie du code est inaccessible aux vecteurs de fuzz; par exemple, un pilote de périphérique pour un périphérique fonctionnant indépendamment de l'interface. Par conséquent, il est difficile de définir une « couverture complète du code » pour les systèmes embarqués - peut-être que seulement 20 % du code embarqué est accessible. La couverture du code consomme également de grandes quantités de cycles flash, RAM et CPU et nécessiterait du matériel spécialisé ou une cible PC pour fonctionner.

Rapport de bogues

Lorsque le test fuzz trouve un vecteur qui provoque un comportement indésirable, nous avons besoin d'informations détaillées. Où le bug est-il arrivé ? Quel est l'état de la pile d'appels ? Quel est le type spécifique de bogue ? Toutes ces informations aident à trier et éventuellement à corriger le bogue.

Le tri des bogues est crucial dans les tests de fuzz. Les nouveaux projets fuzz trouvent souvent de nombreux bugs, et nous avons besoin d'un moyen automatique pour déterminer leur gravité. De plus, les bogues fuzz ont tendance à bloquer les bogues car ils masquent souvent des bogues supplémentaires plus loin dans le chemin du code. Nous avons besoin d'une solution de contournement rapide pour les problèmes qui surviennent lors des tests de fuzz.

Les clients embarqués ne sont pas aussi disposés à révéler leurs informations que les PC. Habituellement, un plantage entraînera simplement la réinitialisation et le redémarrage de l'appareil. Bien que cela soit souhaité sur le terrain, cela efface l'état de l'appareil, ce qui rend difficile de savoir si un crash s'est produit, où et pourquoi il s'est produit, ou le chemin de code emprunté. L'ingénieur doit trouver un vecteur de reproduction cohérent, puis utiliser un débogueur pour tracer le mauvais comportement et trouver le bogue.

Dans les tests fuzz, un test peut générer des milliers de vecteurs de crash pour quelques bogues, donnant la fausse impression d'un système bogué. Il est important de déterminer rapidement quels vecteurs sont associés au même bogue sous-jacent. Pour les appareils intégrés, l'emplacement du plantage lui-même sera généralement unique pour le bogue, et il n'est généralement pas nécessaire de trouver la trace complète de la pile d'appels.

Tests fuzz continus

En raison de la nature stochastique des tests fuzz, les exécuter pendant des périodes plus longues augmente leurs chances de trouver des problèmes. Mais aucun plan de projet ne pourrait absorber les retards d'un long cycle de test fuzz à la fin du développement.

En pratique, les tests fuzz commenceraient sur sa propre branche après le processus de publication. Tous les bogues nouvellement découverts seraient corrigés dans la branche locale, afin que les tests puissent continuer sans que les nouveaux bogues ne bloquent la découverte de bogues supplémentaires. Dans le cadre du cycle de publication, les bogues découverts lors des tests fuzz des versions précédentes seraient évalués pour être inclus dans les nouvelles versions. Enfin, les vecteurs fuzz qui ont découvert un bogue doivent être ajoutés aux processus normaux d'assurance qualité pour vérifier le correctif et s'assurer que ces bogues ne sont pas réintroduits par inadvertance dans le code.

Nous devrions exécuter des tests fuzz d'appareils dans différents scénarios ; par exemple, un appareil répond différemment aux demandes de connexion s'il est en réseau. Il n'est pas pratique d'exécuter des tests fuzz sur tous les scénarios possibles, mais nous pouvons inclure des tests fuzz pour chaque valeur d'état possible. Par exemple, exécutez des tests fuzz avec chaque type de périphérique différent tout en conservant les mêmes variables. Exécutez ensuite différentes valeurs pour une autre variable, telle que l'état de la connectivité réseau, pour un type d'appareil.

Architecture de test Fuzz

Deux architectures de test fuzz importantes sont le fuzz dirigé, où les vecteurs fuzz sont spécifiés par un ingénieur avant le test, et le test fuzz guidé par la couverture, où l'outil fuzz commence par un ensemble initial de vecteurs de test et les mute automatiquement en fonction de la pénétration des paquets. le code.

De plus, tout le code ne s'exécutera pas sur un PC, et le développement d'un simulateur de PC pour une application embarquée peut s'avérer peu pratique, selon ce qui est testé.

Vous trouverez ci-dessous un résumé de quatre architectures de test fuzz :

• Test d'interface direct sur le matériel embarqué :exécution de l'image de production normale sur l'appareil embarqué avec des paquets fuzz injectés sur l'interface
• Test d'injection de paquets (pile) :appelez directement les routines de paquets entrants sans avoir à utiliser l'interface par voie hertzienne
• Fuzzing dirigé avec un simulateur :en utilisant des techniques de simulation sur PC pour développer et tester du code intégré
• Fuzzing guidé par la couverture avec un simulateur (illustré sous Libfuzz ci-dessous)

Plusieurs testeurs de fuzz

Après avoir verrouillé un périphérique intégré avec le verrouillage de l'interface de débogage et le démarrage sécurisé, nous devons envisager des tests fuzz des interfaces de l'appareil. La plupart des outils et concepts utilisés pour sécuriser les serveurs Web peuvent être adaptés pour être utilisés avec des appareils intégrés.

Utilisez le bon outil pour le travail. Le fuzz guidé par la couverture est nécessaire pour les tests de fuzz continus, mais si votre code ne s'exécute que sur du matériel embarqué, les fuzzers dirigés peuvent être un bon choix pour fournir un certain niveau de couverture de test de fuzz.

Enfin, vous devez utiliser plusieurs testeurs de fuzz dans autant de scénarios que possible, car chacun testera l'appareil légèrement différemment, maximisant ainsi la couverture et donc la sécurité de votre appareil intégré.

>> Cet article a été initialement publié le notre site frère, EDN.