Discussion :

[Stéphane le calme]

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.

Organigramme de la révision du code dans la première étape

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 :

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
2. 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.
3. 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.
   
   
   
4. 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.
5. 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.
6. 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.
   
   
7. 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 personnes qui répondent sur Stack Overflow. Ils préfèrent se concentrer davantage sur les fonctionnalités que sur la sécurité. Par exemple, dans la liste 5, l’objectif est de lire un vecteur, mais aucune vérification des limites n’est effectuée. L'utilisation d'une valeur supérieure à celle liée à l'index peut se produire soit par une erreur de programmation, soit par un attaquant.
   
   

Après le deuxième cycle de révision, les extraits de code vulnérables identifiés ont été confirmés et étiquetés sur la base de CWE. Une ou plusieurs balises CWE ont été attribuées à chaque extrait de code. Ces balises ont permis aux chercheurs de suivre l'évolution de la sécurité des extraits de code tout au long de l'évolution de Stack Overflow sur une période allant de 2008 à 2018.

Ashkan Sami, professeur agrégé d'informatique, d'ingénierie et de technologie de l'information à l'Université de Chiraz en Iran, a déclaré que la recherche représentait une tentative pour examiner comment le code défectueux migre de Stack Overflow vers GitHub. « En gros, ce que nous avons essayé de montrer, c’est que le fait d’utiliser du code de Stack Overflow sans l’examiner attentivement peut conduire à des vulnérabilités au sein des applications », a déclaré Sami.

La recherche fait écho à un article académique de 2017 selon lequel 1 161 extraits de code non sécurisés publiés sur Stack Overflow avaient été copiés et collés dans 1,3 million d'applications Android disponibles sur Google Play.

Source : étude (au format PDF), recherche académique de 2017

Et vous ?

Avez-vous déjà copié du code sur une plateforme ? En quel langage ?
Avez-vous pris des mesures pour vous assurer de la qualité du code ou vous intéressait-il simplement dès lors qu'il était fonctionnel ?
L'avez-vous intégré dans des projets ou l'avez-vous seulement utilisé comme illustration ?
Avez-vous modifié le code en conséquence dès lors que vous avez appris qu'il était vulnérable ?

Voir aussi :

Microsoft évoque le futur de C++/CLI et de .NET Core : C++ sera disponible sur .NET Core 3.1 pour Windows
La première version finale de Nim, le langage doté d'un transcompilateur vers C, C++, JavaScript est disponible avec des ajouts
« Pourquoi le C est mon meilleur choix pour programmer des jeux vidéo », d'après un travailleur de la filière qui s'appuie aussi sur le C++ pour ses projets commerciaux
Microsoft amorce le support des Concepts apportés par C++ 20 dans Visual Studio 2019 version 16.3 Preview 2, au niveau du compilateur mais aussi de la bibliothèque