Copier du code sur des plateformes spécialisées et l'utiliser pour ses propres projets peut les rendre vulnérables

D'après une étude

Copier du code sur des plateformes spécialisées et l'utiliser pour ses propres projets peut les rendre vulnérables,
d'après une étude

Un objectif majeur du développement de logiciels est de fournir des logiciels de haute qualité de manière rapide et rentable. La réutilisation du code est une pratique acceptée et une approche essentielle pour atteindre ce principe. Les extraits de code réutilisés proviennent de nombreuses sources différentes et sous différentes formes, par exemple, une bibliothèque tierce, un logiciel open source et des plateformes spécialisées comme la plateforme de Stack Overflow. Le partage d'extraits de code et d'exemples de code est également une pratique d'apprentissage courante. Les novices et encore plus de développeurs expérimentés utilisent des exemples de code et des explications partagées sur des plateformes spécialisées pour apprendre à effectuer de nouvelles tâches de programmation ou à utiliser certaines API.

De nombreuses études ont examiné le flux de connaissances et le partage de connaissances de Stack Overflow dans des référentiels de logiciels open source hébergés dans GitHub. Elles en sont venues à la conclusion selon laquelle les extraits de code trouvés sur Stack Overflow peuvent être toxiques (c'est-à-dire de piètre qualité) et peuvent potentiellement conduire à des violations de licence. La sécurité est un aspect important de la qualité sur lequel la communauté de recherche n'a pas enquêté en détail. Si des extraits de code vulnérables sont migrés depuis Stack Overflow vers des applications, ces applications seront exposées aux attaques. De plus, la plupart des études qui s'y sont intéressées se sont plutôt penchées sur Java et Python.

Dans un document de recherche soumis au service de préimpression ArXiv, six chercheurs en informatique issus de l'Université de Shiraz en Iran, de l'Université polytechnique de Montréal au Québec et de l'Université Chamran en Iran (Morteza Verdi, Ashkan Sami, Jafar Akhondali, Foutse Khomh, Gias Uddin et Alireza Karami Motlagh) se sont fixé pour objectif de comprendre la nature et la prévalence des vulnérabilités en matière de sécurité dans les exemples de code en C++ partagés.

Ils expliquent que « dans les sessions de collaboration impliquant plusieurs codeurs humains, nous avons évalué manuellement les vulnérabilités de sécurité de chaque fragment de code conformément aux instructions de CWE (Common Weakness Enumeration). Parmi les 72 483 extraits de code examinés utilisés dans au moins un projet hébergé sur GitHub, nous avons trouvé un total de 69 extraits de code vulnérables classés dans 29 types. Beaucoup d'extraits de code étudiés ne sont toujours pas corrigés lors du dépassement de pile. Les 69 extraits de code vulnérables trouvés sur Stack Overflow ont été réutilisés dans un total de 2859 projets GitHub. Pour améliorer la qualité des extraits de code partagés sur Stack Overflow, nous avons développé une extension de navigateur qui permet aux utilisateurs de Stack Overflow de rechercher les vulnérabilités dans les extraits de code lorsqu'ils les téléchargent sur la plateforme ».


Pour les besoins de leur étude, ils se sont servis de Syntaxnet, un outil de traitement de langage naturel qui a été utilisé pour détecter les extraits de code contenant des codes C ++ réels. Selon l'équipe, Syntaxnet est l’un des analyseurs syntaxiques les plus précis disponibles. La principale différence entre Syntaxnet et les autres outils de PNL est que Syntaxnet n'utilise pas le sens de la phrase, mais considère également les mots comme étant indépendants les uns des autres. Parmi les 121 892 extraits de code possibles, seuls 72 483 extraits de code étaient en réalité des extraits de code C ++ inclus dans 1 325 réponses.

Afin de rendre le processus de révision plus efficace et systématique, les chercheurs ont créé une application Web dotée d'une interface simple avec une coloration syntaxique spécifique au langage. L'application de révision Web peut marquer les extraits de code comme étant vulnérables, attribuer une ou plusieurs balises CWE pour chaque extrait de code et afficher simultanément tous les codes similaires d'une même réponse.


Trois étudiants en master expérimentés (premier, troisième et sixième auteur) en matière de sécurité C++ ont été choisis pour examiner les extraits de code. Comme indiqué dans la section précédente, seuls 2 056 extraits de code unique devaient être révisés. L’examinateur devait identifier les vulnérabilités selon les critères de CWE appropriés.

Lors de la première étape du processus d’inspection manuelle, l’objectif était de réduire la taille des ensembles de données sans perte de précision. Ainsi, tous les extraits de code qui n'étaient certainement pas vulnérables ont été supprimés. Comme le montre l'organigramme, les trois examinateurs ont inspecté les extraits de code et marqué tout éventuel extrait de code vulnérable comme un code vulnérable. Si une vulnérabilité comportant un extrait de code était perceptible dès le premier tour de contrôle, ils rédigeraient une courte description expliquant pourquoi ils estimaient que l'extrait de code pouvait être vulnérable.

Les étapes spécifiques ont été documentées. Ce processus a pris 868 heures. En revanche, les extraits de code dépourvus de fonctionnalités spécifiques ou utilisés uniquement à des fins pédagogiques (et ne présentant aucune vulnérabilité) ont été supprimés. Au cours du processus de révision, les examinateurs ont été directement en contact les uns avec les autres et ont résolu leur désaccord par des discussions.

Second cycle d'examination

Après cette première étape d’examen approfondi du code, 498 extraits de code vulnérables ont été détectés. La première série de critiques a été présentée à un professeur en sécurité logicielle pour validation. Un groupe de 12 étudiants diplômés ayant déjà suivi des cours sur la sécurité des systèmes et/ou des logiciels au dernier cycle a finalisé la première série de révisions.

La deuxième série de processus d’examen était plus robuste et suivait des directives bien précises. Afin de trouver des vulnérabilités dans les réponses, les examinateurs devaient approfondir le processus et mieux comprendre les extraits de code ainsi que leur évolution. Sur la base des connaissances acquises au cours de la première phase d’examen, les chercheurs ont établi un ensemble de directives expliquées ci-dessous afin de détecter le plus grand nombre possible de vulnérabilités dans les extraits de code sans en manquer aucune :
[LIST=1][*]lire la question correspondante pour répondre avec l'extrait de code vulnérable probable : pour mieux comprendre les raisons pour lesquelles les développeurs ont partagé l'extrait de code sur Stack Overflow[*]lire la dernière version de la réponse, sa description et son évolution au fil du temps : déterminer si la vulnérabilité a été corrigée ou si elle a évolué dans les différentes versions.[*]lire les commentaires des réponses : pour savoir si la vulnérabilité a été signalée à travers les commentaires. Par exemple, dans l'illustration ci-dessous, les premier et second commentaires ont indiqué une vulnérabilité, les troisième et quatrième commentaires ont indiqué une réponse déconseillée. Le code source de la réponse est également inclus dans la liste 1.
[*]rechercher les fonctions obsolètes ou dangereuses dans les extraits de code : Par exemple, la fonction [C]rand ()[/B] est obsolète depuis C ++ 11 et n’est pas recommandée pour la génération de nombres aléatoires et les opérations cryptographiques.[*]vérifier les arguments passés aux fonctions dans l'extrait de code : les types d'arguments et leurs valeurs sont très importants. Par exemple, un grand nombre entier non signé sortant de la limite passé à une fonction qui accepte les entiers signés peut interpréter la valeur en tant que nombre négatif entraînant un comportement non défini ou un plantage du programme.[*]vérifier les utilisations des fonctions en se basant sur les documentations officielles : pour la référence et la documentation appropriée des vulnérabilités découvertes, des documentations officielles ont été largement utilisées tout au long du processus de révision. Par exemple, dans la liste 2, la valeur renvoyée par malloc n’a pas été vérifiée.
[*]rechercher les vulnérabilités logiques dans les extraits de code : en règle générale, la sécurité n’est pas la première priorité des...