Les logiciels d’entreprise étant plus dépendants que jamais des composants open source, un élément important de la sécurité des applications modernes dépend de la capacité de la communauté open source à consolider le code vulnérable. La présentation de Black Hat USA “Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All” abordera certains outils et stratégies importants qui peuvent accélérer les progrès sur ce front.
Jonathan Leitschuh, le premier boursier Dan Kaminsky de HUMAN Security, prévoit d’examiner comment la communauté de la recherche en sécurité peut utiliser la génération automatisée de demandes d’extraction en masse pour collaborer avec les responsables de l’open source d’une manière qui peut faciliter la gestion d’un nombre considérablement plus élevé de problèmes à haut risque. défauts.
Leitschuh a utilisé son année de bourse pour travailler à affiner les outils et les méthodes de mise à l’échelle de la correction des vulnérabilités de sécurité open source. Dark Reading a rencontré Leitschuh pour discuter de sa prochaine conférence et approfondir son travail. (L’interview a été légèrement modifiée pour plus de concision et de clarté.)
Dark Reading : Que pensez-vous du No. 1 plat à emporter sera pour le public lors de votre conférence Black Hat ?
Leitschuh : Ma présentation examinera les vulnérabilités open source et comment plusieurs sont plus répandues que vous ne le pensez. Par exemple, il existe un projet détenu par Perforce, appelé zeroturnaround/zt-zipqui a reçu les trois correctifs de demande d’extraction de sécurité que j’ai tenté de corriger sur l’open source.
Il est important de noter que la découverte ayant le plus grand impact que j’ai l’intention de partager est de savoir comment il est possible de corriger les vulnérabilités de sécurité courantes et répandues à grande échelle. Nous avons la technologie. Tout ce que nous devons faire, c’est en tirer parti.
Mon objectif est de démontrer que la correction de ces vulnérabilités n’est pas un problème interactif. Nous pouvons le résoudre avec les mathématiques, la science, la technologie et la sécurité. Vous devez être accessible, flexible et ouvert d’esprit si vous voulez que vos correctifs proposés soient acceptés.
Ce n’est pas que les gens dorment au volant quand il s’agit de vulnérabilités. Souvent, ils ne sont tout simplement pas conscients de certains problèmes et, pour aggraver les choses, le Web n’est pas sécurisé par défaut.
Lecture sombre : Lorsque nous nous sommes parlé pour la première fois au début de l’année, vous étiez juste en train de vous mouiller les pieds dans la fraternité et de planifier votre année. Pouvez-vous me faire le point sur les progrès que vous avez réalisés dans l’utilisation de CodeQL, OpenRewrite et d’autres outils pour étendre l’atténuation des vulnérabilités open source ?
Leitschuh : J’ai fini par devoir réimplémenter des fonctionnalités, notamment l’analyse des flux de données et des flux de contrôle, qui manquaient ou étaient partiellement implémentées dans OpenRewrite afin de prendre en charge les vulnérabilités que je comptais corriger. La fonctionnalité Control Flow était particulièrement délicate mais a été possible grâce à une excellente collaboration avec mon stagiaire, Shyam Mehta. Il avait suivi quelques cours à l’université que je n’avais pas suivis, en particulier un sur les compilateurs qui était particulièrement utile dans notre travail.
Nous avons généré plus de 400 demandes d’extraction pour corriger de nouvelles instances d’anciennes vulnérabilités issues de mes recherches précédentes et généré plus de 170 demandes d’extraction pour corriger de nouvelles vulnérabilités qui n’auraient pas été possibles sans OpenRewrite.
Lecture sombre : avez-vous rencontré des surprises ?
Leitschuh : Les commentaires des mainteneurs ont été, en général, positifs, mais il est toujours intéressant de voir à quel point vous devez être prudent avec les mainteneurs d’OSS. Il est très important de s’assurer que le correctif automatisé que vous effectuez ressemble au code environnant. L’un des plus gros refus des responsables que j’ai reçus concerne le fait de ne pas inclure les tests unitaires avec les demandes d’extraction. Malheureusement, leur base de code est le plus souvent beaucoup trop complexe pour générer automatiquement un test unitaire en plus du correctif.
Lecture sombre : Quelle a été la découverte/technique/application d’outils la plus percutante que vous avez découverte au cours de l’année ?
Leitschuh : Pour commencer, j’ai dû repartir de zéro et procéder à une analyse des données. L’utilisation de CodeQL était essentielle car j’avais besoin de traduire mes connaissances non seulement dans différents langages de programmation, mais également d’un langage de requête à un langage procédural.
Shyam a contribué à s’assurer que je construisais correctement cette nouvelle fonctionnalité, dont nous avions besoin pour la vulnérabilité de sécurité finale : Zip Slip, qui décompresse un fichier zip de telle manière que l’on peut écraser arbitrairement le contenu du fichier, permettant potentiellement l’exécution de code à distance .
À noter que Snyk avait déjà effectué des travaux à ce sujet, mais certaines des mesures d’atténuation que leur chercheur a travaillé avec les responsables pour élaborer se sont avérées ne pas avoir été correctes à 100 %.
Lecture sombre : Avez-vous un bon exemple de vos techniques en action ?
Leitschuh : Au fur et à mesure que je prenais connaissance des recherches existantes, je savais qu’il y avait plus de cas de vulnérabilités de sécurité à découvrir.
À partir d’une requête CodeQL, l’équipe GitHub Security Lab m’a fourni une liste de 900 référentiels potentiellement vulnérables à Zip Slip. Sur les 900, nous avons fait 86 demandes d’extraction de correctif Zip Slip à ce jour, ce qui signifie 86 vulnérabilités de sécurité critiques qui ont maintenant des correctifs possibles.
Lecture sombre : Y a-t-il des détails sur lesquels vous espérez que la communauté pourra participer et travailler ?
Leitschuh : Il y a encore un écart important où nous avons besoin de l’aide de la communauté, en particulier autour de l’écart entre les 900 référentiels et les 86 correctifs.
La liste des projets comprenait des projets archivés et d’autres projets non maintenus, ce qui signifie que les vulnérabilités ne seront peut-être pas corrigées de sitôt, mais au moins elles sont maintenant visibles, ainsi que des correctifs potentiels.
Il existe une multitude de vulnérabilités open source qui n’attendent que d’être corrigées avec des techniques plus avancées.
Lecture sombre : En pratique, que pensez-vous qu’il faudra aux praticiens pour mettre vos apprentissages en action ?
Leitschuh : Idéalement, la première étape serait d’apprendre CodeQL afin qu’ils puissent exprimer des recherches de vulnérabilités. Puis apprendre à utiliser quelque chose comme OpenRewrite afin de générer des correctifs. Ensuite, les meilleures pratiques concernant la soumission de PR en masse.
Il serait également avantageux pour les praticiens d’avoir au moins une compréhension de base du langage utilisé dans un projet particulier, car cela leur permettrait de mieux comprendre les vulnérabilités et les risques encourus.
La curiosité est également un élément essentiel pour qu’ils puissent explorer et approfondir la vulnérabilité. Par exemple, un praticien peut exécuter une recherche rapide avec GitHub Code Search, compiler des exemples, puis écrire plusieurs tests unitaires pour évaluer comment vous pouvez aborder la vulnérabilité de front.
Lecture sombre : Comment avez-vous changé d’avis au cours de l’année sur la façon dont vous pensez que nous devrions travailler pour résoudre les plus gros problèmes de sécurité de la chaîne d’approvisionnement des logiciels aujourd’hui ?
Leitschuh : La chaîne d’approvisionnement de la sécurité logicielle est un peu différente car mon travail porte sur les vulnérabilités réelles du projet. Cependant, il y a beaucoup de valeur dans les analyses approfondies des vulnérabilités de sécurité, mais il est devenu très clair pour moi qu’il y a beaucoup de vulnérabilités de sécurité à la surface.
Nous savons que ces vulnérabilités existent. Vous mettez les scanners entre les mains d’un mainteneur, ils voient beaucoup de bruit. Ils doivent filtrer ce qui est bon et ce qui est mauvais. Avec une demande d’extraction, même si vous ne la corrigez pas, cela, espérons-le, durcira votre logiciel.
Je le savais avant d’arriver, mais il est devenu très clair pour moi à quel point les responsables peuvent être pointilleux. Il y a une réaffirmation que vous devez obtenir le code et le formatage corrects ; vous ne pouvez pas lésiner sur la messagerie et réagir globalement en conséquence lorsque vous voyez les réactions des responsables.
Les gens obtiennent leur ego enveloppé dans leur logiciel, dont je peux certes être coupable. Vous les défiez d’une certaine manière – même en agissant comme une menace. Par exemple, vous n’avez pas simplement écrit ceci de manière erronée, vous l’avez écrit d’une manière qui constitue une véritable faille de sécurité. C’est plus gros qu’un insecte. Il est important d’avoir un respect sain pour l’aspect humain des logiciels open source.
Lecture sombre : Pourquoi pensez-vous qu’il est important pour les praticiens de la sécurité et les chercheurs d’apporter plus de respect à la table pour les mainteneurs de projets OSS ? Comment la cybersécurité peut-elle s’améliorer en conséquence ?
Leitschuh : Je comprends certainement le sort d’un mainteneur open source. C’est difficile et exigeant, et la plupart donnent de leur temps. Ils constituent une ligne de défense importante contre les acteurs malveillants et doivent gérer de larges pans de projets open source.
Vous devez être conscient que les mainteneurs et les propriétaires des projets font cela pendant leur temps libre, il est donc important de coopérer activement avec eux, au lieu de s’attendre à ce qu’ils acceptent toujours vos modifications suggérées dès le départ.
Nous faisons de notre mieux en matière de cybersécurité lorsque nous travaillons en collaboration. Les mainteneurs font partie du processus et doivent être identifiés et respectés en tant que tels.
Lecture sombre : Quelle est la prochaine étape pour vous et vos recherches à la sortie de la bourse ?
Leitschuh : Je ne suis pas encore tout à fait sûr. J’aimerais voir cette recherche portée à un niveau supérieur. Certaines vulnérabilités, telles que l’injection SQL, peuvent être découvertes de manière déterministe avec le suivi des flux de données et des altérations (car CodeQL le fait déjà).
Le plus compliqué est de transformer une détection en un correctif. Les développeurs de logiciels écrivent du code de différentes manières, essayer d’écrire des correctifs pour toutes les différentes façons dont les développeurs peuvent écrire du code est une tâche difficile.
Leitschuh est co-présentateur avec Patrick Way de Moderne (l’un des mainteneurs open source d’OpenRewrite) et Shyam Mehta, un ingénieur logiciel étudiant à l’Université de Pennsylvanie. Way a enseigné à Leitschuh “OpenRewrite à partir de zéro”, et Mehta “a joué un rôle déterminant tout au long de la bourse”, déclare Leitschuh.
“Chaque fois que j’ai besoin de résoudre un problème et que je peux avancer un peu plus lentement, ou que j’ai besoin de réfléchir davantage à quelque chose pendant que je le construis, je programme en binôme avec [Mehta], où il écrit le code et je fournis des instructions. Il a également aidé à utiliser l’analyse de flux de contrôle, a créé l’interface utilisateur pour deux exemples de graphiques de flux et, avec le grand débogage, dit “Leitschuh.