Révéler des vulnérabilités cachées dans les composants logiciels

Aujourd'hui, le développement logiciel implique souvent d'utiliser des Composants ou des bibliothèques créés par d'autres. Ces composants sont stockés dans des lieux centraux, ce qui les rend accessibles aux développeurs. Cependant, utiliser ces composants peut exposer le logiciel à divers problèmes, y compris des Vulnérabilités, des problèmes de licence et des bugs. Du coup, comprendre ces composants est crucial, et des outils ont été créés pour aider à analyser les Dépendances logicielles utilisées.

Une des principales préoccupations concerne les dépendances cachées qui peuvent apparaître lorsque le code est dupliqué ou modifié. Cela s'appelle le Clonage, où le code est copié directement, ou le shading, où le code est déplacé dans différents espaces de noms. Ces pratiques peuvent rendre difficile l'identification des failles de sécurité.

Cet article discute d'une nouvelle méthode pour repérer les copies vulnérables de code dans un dépôt populaire. Cette méthode est simple car elle ne nécessite pas de configurations compliquées ou de bases de données spéciales. Au lieu de ça, elle part d'une liste de vulnérabilités connues et examine un grand nombre d'exemples de code pour trouver des copies potentiellement vulnérables. Les résultats montrent que beaucoup d'outils existants passent souvent à côté de ces risques cachés.

#Importance des Composants Logiciels

Le développement logiciel moderne repose de plus en plus sur des bibliothèques et des composants. Cela permet aux développeurs de gagner du temps et des efforts en réutilisant du code existant au lieu de tout écrire depuis zéro. Cependant, cette approche crée aussi des défis. Les vulnérabilités peuvent se propager à travers ces composants si ils ne sont pas à jour. Des événements comme la violation de données d'Equifax et l'exploitation Log4Shell soulignent à quel point ces problèmes peuvent être sérieux lorsque les développeurs utilisent des composants obsolètes ou vulnérables.

Un autre problème est que tout le code n'est pas toujours visible dans les configurations de construction. Cela signifie que certaines vulnérabilités peuvent passer inaperçues. Des outils existent pour scanner et analyser les dépendances pour identifier d'éventuelles vulnérabilités. Ces outils vérifient les vulnérabilités connues listées dans des bases de données publiques et notifient les développeurs quand ils doivent faire des mises à jour.

#Aperçu des Outils de Détection des Vulnérabilités

Les outils d'analyse de composition logicielle (SCA) sont conçus pour aider les développeurs à comprendre leurs dépendances. Ils se composent généralement de deux parties principales : le scan des dépendances et la vérification de celles-ci par rapport aux bases de données de vulnérabilités connues. Chaque outil a sa propre façon de faire correspondre et identifier ces dépendances, ce qui peut entraîner des erreurs.

Bien que ces outils soient utiles, ils ne sont pas parfaits. Ils peuvent manquer des vulnérabilités, surtout si le logiciel découvre dynamiquement des composants à l'exécution ou si le code a été cloné ou shade. Des problèmes peuvent surgir lorsque les développeurs copient sans le savoir du code à partir de sources peu fiables ou lorsque des bibliothèques utilisées par d'autres bibliothèques créent des situations complexes.

#Défis du Clonage et du Shading

Le clonage peut se produire lorsque les développeurs copient directement du code dans leurs projets, ce qui peut introduire des vulnérabilités cachées par le processus de clonage. Ces vulnérabilités peuvent être difficiles à détecter, surtout puisque le code copié peut ne pas ressembler à l'original.

Le shading est une autre pratique où des paquets entiers sont renommés. Cela peut se produire durant le processus de construction, rendant plus difficile pour les outils de trouver et analyser les vulnérabilités. Bien que le shading puisse être bénéfique, en rendant le code plus petit et possiblement plus sécurisé en éliminant des fonctionnalités inutiles, cela crée aussi des zones d'ombre pour les outils SCA qui suivent les dépendances.

En Java, un problème courant similaire à ce qu'on appelle "l'enfer des DLL" peut se produire lorsque différentes versions de la même bibliothèque entrent en conflit. Cela conduit souvent à des erreurs qui ne se manifestent que lorsque le logiciel est exécuté, compliquant encore plus les choses.

#Détection de Code Vulnérable

Pour résoudre ces problèmes, une nouvelle approche pour analyser les composants Java a été développée. Cette méthode se concentre sur la recherche de code cloné dans le dépôt populaire Maven sans avoir besoin d'une base de données personnalisée. En partant d'un ensemble de vulnérabilités connues, la méthode récupère un grand nombre de clones potentiels du dépôt et les analyse pour détecter des vulnérabilités.

Après avoir scanné des milliers de composants, un nombre significatif de clones vulnérables confirmés a été trouvé. Malheureusement, beaucoup d'outils SCA existants ont raté ces vulnérabilités. Les résultats ont conduit à des mises à jour dans la base de données des avis de sécurité de GitHub, soulignant le besoin d'outils meilleurs dans ce domaine.

#L'Expérience

Pour explorer la fréquence du shading, une étude a été menée pour examiner les fichiers Maven sur GitHub. Les résultats initiaux ont indiqué qu'un petit pourcentage de ces fichiers utilisaient le plugin Maven shade pour le shading, révélant que les pratiques de shading ne sont pas rares.

L'étude visait aussi à répondre à des questions essentielles sur la fréquence du shading non suivi et quels risques cela pose. Ces informations étaient importantes pour évaluer l'efficacité des outils de détection de vulnérabilités actuels.

#Détection des Zones d'Ombre

Pour détecter ces vulnérabilités cachées efficacement, un pipeline de traitement a été créé. Ce pipeline prend un artefact vulnérable connu et une vulnérabilité comme entrée, analysant la présence potentielle de la vulnérabilité dans l'artefact donné.

La conception de cet outil se concentre sur la précision et la légèreté. Il n'exige pas de maintenir un index séparé, ce qui le rend plus efficace. La méthodologie implique d'extraire des signatures de classes pour identifier des clones potentiels et vérifier leur présence par des tests conçus pour vérifier les vulnérabilités dans ces clones.

Le but est de montrer qu'avec des outils simples, on peut détecter plus d'artefacts vulnérables, soulignant le besoin de surmonter les limitations des outils SCA existants qui fonctionnent principalement à partir des métadonnées.

#Méthodologie de Détection

Dans le pipeline de détection, plusieurs étapes sont impliquées :

1. Récupération des Binaires et des Sources : L'outil récupère le code binaire et source de l'artefact donné pour l'analyser.
2. Sélection de Classes : Il extrait les noms de classes de l'artefact, utilisés pour interroger le dépôt à la recherche de clones potentiels.
3. Récupération des Correspondances de Classes : L'outil interroge le dépôt pour trouver d'autres artefacts contenant des classes avec des noms correspondants, consolidant ces correspondances pour trouver des clones probables.
4. Analyse des Clones : Le pipeline effectue une analyse pour détecter des clones en comparant les structures des classes identifiées.
5. Vérification des Vulnérabilités : Des tests sont effectués sur les clones pour confirmer si la vulnérabilité connue est présente.

Cette approche structurée permet d'identifier des clones vulnérables dans un laps de temps relativement court, soulignant le potentiel d'amélioration de la détection des vulnérabilités précédemment négligées.

#Évaluation des Résultats

Les expériences réalisées ont révélé un total de 727 artefacts vulnérables confirmés à travers diverses vulnérabilités. Après avoir affiné les résultats pour éliminer les doublons et se concentrer sur des cas uniques, le nombre de découvertes a considérablement diminué, indiquant que de nombreuses copies vulnérables étaient effectivement présentes.

Les vulnérabilités les plus fréquemment détectées dans l'analyse concernaient des bibliothèques souvent utilisées dans le traitement JSON. Fait intéressant, beaucoup d'entre elles ont été trouvées en utilisant des techniques de shading qui compliquent leur détection.

Bien que plusieurs outils SCA aient été testés sur les composants originaux, leur performance variait. Certains outils ont pu identifier la plupart des vulnérabilités, mais beaucoup n'ont pas réussi à détecter les problèmes dans les composants clonés. Une infime partie des clones testés a été reconnue par ces outils, mettant en lumière un fossé important dans ce que les outils SCA actuels peuvent analyser efficacement.

#Limitations de l'Étude

Bien que l'analyse visait la précision, il y avait des limitations. Les tests peuvent ne pas toujours refléter l'ensemble des vulnérabilités, car certains rapports sont flous ou vagues. Certains éléments, comme la connectivité réseau, n'ont pas été inclus dans les tests pour les garder rapides et efficaces.

De plus, l'analyse n'a pas pu détecter tous les clones, surtout ceux impliquant des niveaux plus profonds de modification de code ou des changements personnalisés au-delà d'un simple renommage. L'étude a reconnu qu'il n'est pas faisable de trouver chaque artefact vulnérable, mais l'approche démontre qu'il y a un problème significatif qui mérite de l'attention.

La dépendance au code source limite aussi la détection aux composants basés sur Java, excluant d'autres langages qui peuvent se compiler en bytecode Java.

#Conclusion

Les résultats de cette étude indiquent que les méthodes existantes pour détecter les vulnérabilités dans les composants logiciels nécessitent une amélioration. Les problèmes de clonage et de shading entraînent des vulnérabilités cachées qui ne sont pas actuellement abordées par de nombreux outils disponibles aujourd'hui.

La recherche soutient l'idée que les outils SCA devraient inclure des mécanismes d'analyse plus profonds qui prennent en compte plus que juste les métadonnées du projet. Avec de nombreuses vulnérabilités encore non découvertes à cause de ces pratiques, il y a un besoin pressant de techniques de détection améliorées pour garantir la sécurité des logiciels.

Les preuves montrent que traiter ces zones d'ombre peut considérablement améliorer la détection des vulnérabilités, menant à de meilleures pratiques de développement logiciel.