Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’analyse du firmware identifie les appels de fonctions potentiellement dangereux dans les fichiers exécutables pris en charge extraits d’images du firmware. Ces résultats peuvent vous aider à identifier des schémas d’implémentation nécessitant une revue de sécurité supplémentaire et à prioriser les binaires en fonction de leur exposition potentielle.
Cet article explique les signaux d’appel de fonction non sécurisés que vous pouvez voir dans les résultats d’analyse du firmware. Il décrit les fichiers pris en charge, les limitations de couverture, et la manière d’évaluer les résultats dans le contexte de l’exécutable et de l’appareil.
Note
La présence d’un appel de fonction non sécurisé ne signifie pas nécessairement qu’un exécutable ou un appareil est vulnérable. Le risque réel dépend de la manière dont la fonction est utilisée, de la capacité d’entrée non fiable à y parvenir, et de la manière dont l’exécutable est exposé et protégé.
Signaux d’appel de fonction non sécurisés dans l’analyse du firmware
L’analyse des appels de fonctions non sécurisés réalise une analyse statique des exécutables pris en charge au format ELF (Executable and Linkable Format). Il identifie les références à des fonctions pouvant contribuer à des problèmes de sécurité lorsqu’elles sont utilisées sans validation d’entrée appropriée, vérification des bornes, validation de la taille du tampon ou autres contrôles de codage sécurisés.
Certaines fonctions de gestion de la mémoire peuvent contribuer à des problèmes de débordement de tampon ou à d’autres conditions de corruption de mémoire lorsqu’elles sont mal utilisées. Selon le chemin de code affecté et les mesures d’atténuation disponibles, un attaquant peut utiliser ces conditions pour perturber l’appareil ou exécuter du code non autorisé.
Chaque résultat représente un signal plutôt qu’une détermination de vulnérabilité. Évaluez les signaux ensemble et dans le contexte du rôle de l’exécutable dans le firmware.
Fonctions potentiellement dangereuses
Certaines fonctions de bibliothèque peuvent être risquées car elles ne garantissent pas intrinsèquement la taille ou la fiabilité des données qu’elles traitent. Par exemple, des fonctions telles que strcpy et strcat peuvent contribuer à des conditions de débordement de tampon si un programme copie une entrée surdimensionnée ou non fiable dans un tampon de destination.
Une référence rapportée indique que l’analyse du firmware a identifié une fonction suivie dans l’exécutable. Cela n’établit pas que la fonction est mal utilisée. La fonction peut être utilisée avec des garanties, telles que vérifier la longueur d’entrée, fournir suffisamment d’espace de destination ou limiter l’entrée aux données fiables.
Lors de la modification du code source, utilisez des fonctions de gestion de chaînes qui acceptent la taille du tampon de destination, et validez les longueurs d’entrée avant de copier ou concaténer les données. Assurez-vous que le résultat se termine par un caractère nul et gérez les cas de troncature ou d’erreur. Les fonctions bornées telles que strncpy et strncat peuvent réduire le risque par rapport aux alternatives non bornées, mais elles doivent néanmoins être utilisées avec des calculs corrects de taille de tampon.
L’ensemble des fonctions suivies peut évoluer au fur et à mesure de l’évolution de cette fonctionnalité. Interprétez le nom de la fonction et le compte comme un point de départ pour la revue de code plutôt que comme un inventaire complet de tous les risques liés à la sécurité mémoire ou à l’exécution de commandes.
Informations sur les appels en réseau
L’analyse du firmware indique également lorsque des appels de fonctions liés au réseau sont identifiés dans un exécutable analysé. Utilisez ce signal pour aider à prioriser les exécutables pour une révision plus approfondie. Il ne détermine pas si l’exécutable accepte des connexions distantes, communique en dehors de l’appareil, ou s’il est joignable dans l’environnement déployé.
Lors de la priorisation des résultats, pensez à examiner d’abord des exécutables contenant à la fois des appels de fonctions non sécurisés et des appels liés au réseau. Ces exécutables peuvent traiter les données reçues d’un réseau et justifier une enquête plus précoce.
Chemin exécutable et nombre d’appels
Les résultats sont associés au chemin exécutable extrait de l’image du firmware. Le nombre d’appels de fonctions indique combien de références à une fonction suivie ont été identifiées pour cet exécutable. Un nombre plus élevé peut indiquer plus de lieux à examiner, mais cela ne signifie pas en soi une plus grande gravité ou une plus grande exploitabilité.
Le même exécutable peut apparaître à plusieurs emplacements extraits, et différents exécutables peuvent contenir des références à la même fonction. Utilisez le chemin de l’extracteur et la version du firmware pour identifier le bon composant source ou l’artefact fournisseur.
Fichiers pris en charge et couverture
L’analyse des appels de fonction non sécurisés est disponible en préversion et s’applique aux exécutables ELF en espace utilisateur pris en charge extraits d’images de micrologiciel basées sur Linux.
Les fichiers modules du noyau Linux (.ko) ne sont pas inclus car l’aperçu est limité à l’analyse exécutable en espace utilisateur.
L’aperçu prend en compte les architectures processeurs suivantes :
- AMD64 ou x86-64
- ARM64 ou AArch64
- ARM32
- MIPS32 (big-endian et little-endian)
Exigences binaires
L’exécutable doit conserver des informations permettant d’analyser le firmware pour identifier les fonctions qu’il utilise. Un binaire lié statiquement ou dépouillé peut ne pas produire de résultats lorsque les noms de fonctions ou autres informations requises ne sont pas disponibles.
Une image de firmware peut réaliser avec succès d’autres activités d’analyse sans produire de résultats d’appels de fonction non sécurisés. Chaque analyseur de firmware a ses propres besoins en fichiers, architecture et métadonnées.
Utiliser conjointement des données d’appel de fonction non sécurisées
Chaque signal offre une perspective différente sur le risque potentiel :
| Signal | Ce que cela vous aide à comprendre |
|---|---|
| Chemin exécutable | Quel fichier exécutable extrait contient les appels identifiés. |
| Nombre d’appels de fonctions non sécurisées | Le nombre total d’appels de fonctions non sécurisées identifiés dans l’exécutable. |
| Nombre d’appels réseau | Est-ce que le comportement lié au réseau justifie une priorité donnée à l’exécutable pour un examen plus approfondi. Le nombre n’établit pas l’accessibilité à distance. |
Nombre d’appels <function name> |
Combien de références à la fonction nommée ont été identifiées dans l’exécutable ? Utilisez le comptage spécifique à la fonction pour concentrer un examen approfondi sur les contrôles de sécurité applicables, tels que la taille du tampon, la validation des entrées, la gestion des chaînes de format, les permissions mémoire ou la validation des commandes-entrées. |
Des comptages spécifiques à chaque fonction sont fournis pour les fonctions suivantes :
strcpystrcatprintffprintfsprintfsystemmmappopen
Plutôt que de vous fier à un seul champ, évaluez ces signaux ensemble pour comprendre quels exécutables nécessitent un examen le plus immédiat.
Considérations importantes
Interprétation des résultats nuls et vides
Les résultats peuvent afficher un nombre de zéro pour un exécutable ou omettre complètement un exécutable. Un décompte de zéro signifie que l’exécutable a été analysé, mais que l’analyse n’a identifié aucun appel surveillé pour ce champ.
Si un exécutable n’apparaît pas dans les résultats, ne supposez pas qu’il ne contient aucun appel de fonction non sécurisé. L’analyse du firmware n’a peut-être pas pu analyser l’exécutable car il utilise une architecture non prise en charge ou ne contient pas les informations nécessaires pour identifier les références de fonction.
Une liste de résultats vide signifie qu’aucun résultat d’appels de fonction non sécurisés n’est disponible pour l’image du firmware. Cela ne signifie pas que le firmware ne contient aucun appel de fonction non sécurisé.
Aucun résultat ne peut apparaître lorsque :
- Aucun exécutable en espace utilisateur ELF n’a été extrait.
- Les exécutables extraits utilisent des architectures non prises en charge.
- Un binaire statique ou dépouillé ne contient pas assez d’informations d’identification.
- Le fichier extrait est un module du noyau Linux exclu.
- L’image du firmware a été analysée avant que l’analyse des appels de fonction non sécurisés ne soit disponible.
- L’extraction ou l’analyse n’ont pas abouti avec succès.
Note
Un résultat vide ne confirme pas que le firmware ne contient aucun appel de fonction non sécurisé. Pour recevoir l’analyse actuelle d’une image traitée avant la publication de l’aperçu des appels de fonction non sécurisés, téléchargez à nouveau l’image du firmware.
Pour savoir comment télécharger une image et consulter ses résultats, voir Analyser une image de firmware avec le service d’analyse de firmware. Pour évaluer les protections associées du compilateur et de l’éditeur de liens, consultez l’onglet Durcissement binaire pour le même exécutable.