IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Des chercheurs ont secrètement tenté d'ajouter des vulnérabilités au noyau Linux
Et ont fini par être bannis

Le , par Stéphane le calme

69PARTAGES

26  0 
Avec plus de 28 millions de lignes de code, le noyau Linux est l'un des plus grands projets logiciels de l'histoire moderne. Des contributeurs du monde entier et de différents domaines soumettent chaque jour un grand nombre de correctifs aux responsables du noyau Linux, afin qu'ils soient examinés avant d'être officiellement fusionnés avec l'arborescence officielle du noyau Linux.

Ces correctifs pourraient aider à corriger un bogue ou un problème mineur dans le noyau, voire même introduire une nouvelle fonctionnalité.

Cependant, certains contributeurs ont choisi de soumettre des correctifs contenant furtivement des vulnérabilités de sécurité au noyau Linux et ils ont été pris la main dans le sac par les responsables du noyau Linux.

Des chercheurs de l'Université américaine du Minnesota rédigeaient un document de recherche sur la possibilité de soumettre des correctifs à des projets open source contenant des vulnérabilités de sécurité cachées afin de mesurer scientifiquement la probabilité que ces correctifs soient acceptés et fusionnés. Ce qui pourrait rendre les projets open source vulnérables à diverses attaques.

Ils ont utilisé le noyau Linux comme l'une de leurs principales expériences, en raison de sa réputation bien connue et de son adaptation dans le monde entier.

Ces chercheurs ont soumis des correctifs qui ne semblaient pas résoudre complètement les problèmes associés dans le noyau, mais qui ne semblaient pas tout de suite introduire une faille de sécurité. Un certain nombre de ces correctifs qu'ils ont soumis au noyau ont en effet été fusionnés avec succès dans l'arborescence du noyau Linux.

Cependant, ils ont été pris par les responsables du noyau Linux et ont été publiquement humiliés. Dans un e-mail de Greg Kroah-Hartman, l'un des principaux responsables de la maintenance du noyau Linux, leur approche a été divulguée et leurs soi-disant « correctifs pour débutants » ont été jetés aux orties.

En réponse à Aditya Pakki qui lui disait :

« Greg,

« Je vous demande respectueusement de cesser et de vous abstenir de porter des accusations farfelues à la limite de la calomnie.

« Ces correctifs ont été envoyés dans le cadre d'un nouvel analyseur statique que j'ai écrit et sa sensibilité n'est évidemment pas excellente. J'ai envoyé des correctifs dans l'espoir d'obtenir des commentaires. Nous ne sommes pas des experts du noyau Linux et faire ces déclarations à plusieurs reprises est dégoûtant à entendre.

« De toute évidence, c'est une mauvaise démarche, mais vos préjugés sont si forts que vous faites des allégations sans fondement et ne nous accordez pas le bénéfice du doute.

«  Je n'enverrai plus de correctifs en raison de l'attitude non seulement indésirable, mais aussi intimidante envers les débutants et les non-experts ».

Et Greg de répondre :

« Vous et votre groupe avez publiquement admis avoir envoyé des correctifs bogués pour voir comment la communauté du noyau y réagirait, et publié un article basé sur ce travail.

« Maintenant, vous soumettez à nouveau une nouvelle série de correctifs manifestement incorrects, alors que suis-je censé penser d'une telle chose?

« De toute évidence, ils n'ont PAS été créés par un outil d'analyse statique qui est de toute intelligence, car ils sont tous le résultat de modèles totalement différents, et qui ne corrigent évidemment rien du tout. Alors, que suis-je censé penser ici, à part le fait que vous et votre groupe continuez à mener des expériences sur les développeurs de la communauté du noyau en envoyant des correctifs aussi absurdes ?

« Lors de la soumission de correctifs créés par un outil, tous ceux qui le font les soumettent avec des mots tels que "trouvés par l'outil XXX, nous ne savons pas si cela est correct ou non, veuillez nous en informer" ce qui n'est PAS du tout ce que vous avez fait ici. Vous ne demandiez pas d'aide, vous affirmiez qu'il s'agissait de correctifs légitimes, ce que vous SAVIEZ être incorrect.

« Quelques minutes avec n'importe qui avec un semblant de connaissance de C peut voir que vos soumissions ne font rien du tout, alors penser qu'un outil les a créées, puis que vous pensiez qu'il s'agissait d'un "correctif" valide est totalement négligent de votre part, pas de la nôtre. Vous êtes le fautif, ce n'est pas notre travail d'être les sujets de test d'un outil que vous créez.

« Notre communauté accueille les développeurs qui souhaitent aider et améliorer Linux. Ce n'est PAS ce que vous essayez de faire ici, alors n'essayez pas de le dépeindre de cette façon.

« Notre communauté n'apprécie pas d'être expérimentée, et d'être "testée" par des soumissions de correctifs connus qui ne font rien exprès, ou introduisent des bogues exprès. Si vous souhaitez faire un travail comme celui-ci, je vous suggère de trouver une autre communauté sur laquelle exécuter vos expériences, vous n'êtes pas les bienvenus ici.

« Pour cette raison, je vais maintenant devoir interdire toutes les contributions futures de votre université et supprimer vos contributions précédentes, car elles ont été manifestement soumises de mauvaise foi dans l'intention de causer des problèmes ».

Apparemment, Greg et un certain nombre d'autres mainteneurs n'étaient pas satisfaits de la situation étant donné que ces expériences prennent de leur temps et leurs efforts. Greg a annoncé que le noyau Linux interdirait toutes les contributions de l'Université du Minnesota, tous les correctifs qu'ils avaient précédemment soumis vont être supprimés du noyau et aucun nouveau correctif ne sera accepté de leur part à l'avenir.

Le document de recherche sur lequel ils ont travaillé a été publié en février 2021; il y a environ deux mois. Dans l'article, ils divulguent leur approche et les méthodes qu'ils ont utilisées pour insérer les vulnérabilités dans le noyau Linux et d'autres projets open source. Ils affirment également que la majorité des vulnérabilités qu'ils ont secrètement essayé d'introduire dans divers projets open source ont réussi à être insérées à environ 60% en moyenne:


On ne sait toujours pas à l'heure actuelle quels autres projets open source ils ont tenté de détourner, et quel est le nombre réel de vulnérabilités qu'ils ont réussi à insérer dans divers projets open source.

Greg a envoyé un autre e-mail dans lequel il annule la plupart des correctifs de l'Université du Minnesota du noyau Linux, et met certains d'entre eux en attente.

« J'avais l'intention de le faire depuis un certain temps, mais les événements récents m'ont finalement obligé à le faire maintenant.

« Les validations des adresses @ umn.edu ont été soumises de "mauvaise foi" pour essayer de tester la capacité de la communauté du noyau à examiner les modifications "malveillantes connues". Le résultat de ces soumissions peut être trouvé dans un article publié au 42nd IEEE Symposium on Security and Privacy intitulé "Open Source Insecurity: Stealthily Introducing Vulnerabilities via Hypocrite Commits" écrit par Qiushi Wu (Université du Minnesota) et Kangjie Lu (Université de Minnesota).

« Pour cette raison, toutes les soumissions de ce groupe doivent être retirées de l'arborescence du noyau et devront être réexaminées pour déterminer si elles sont réellement un correctif valide. Jusqu'à ce que ce travail soit terminé, supprimez cette modification pour vous assurer qu'aucun problème n'est introduit dans la base de code ».

L'université du Minnesota, quant à elle, a publié le communiqué suivant :

« Les dirigeants du département d'informatique et d'ingénierie de l'Université du Minnesota ont appris aujourd'hui les détails de la recherche menée par l'un de ses membres du corps professoral et des étudiants diplômés sur la sécurité du noyau Linux. La méthode de recherche utilisée a soulevé de sérieuses préoccupations dans la communauté du noyau Linux et, à partir d'aujourd'hui, cela a abouti à l'interdiction de l'Université de contribuer au noyau Linux.

« Nous prenons cette situation très au sérieux. Nous avons immédiatement suspendu cette ligne de recherche. Nous étudierons la méthode de recherche et le processus par lesquels cette méthode de recherche a été approuvée, déterminerons les mesures correctives appropriées et nous protégerons contre les problèmes futurs, si nécessaire. Nous rendrons compte de nos résultats à la communauté dès que possible ».

Sources : Greg Kroa-Hartman (1, 2), université du Minnesota

Et vous ?

Que pensez-vous de cette approche ? Pensez-vous que l’attitude du chercheur était justifiée au nom de la science et de la sécurité ? Ou pensez-vous que les responsables du noyau Linux avaient raison de les bannir du noyau, et que cette approche ne devrait pas être encouragée ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de BugFactory
Membre expérimenté https://www.developpez.com
Le 22/04/2021 à 13:35
Si j'ai bien compris, le résultat des travaux de ces chercheurs, c'est :
- il y a maintenant une multitude de vulnérabilités dans un nombre indéterminé de projets open source,
- leur université est bannie de toute contribution au noyau Linux,
- les responsables de Linux ont gaspillé du temps à s'occuper de ça, et vont devoir en gaspiller davantage.

L'intérêt de ces recherches, ce serait de détecter des failles dans le processus de validation de projets open source. Mais la liste des projets open source où il a été possible d'insérer des failles n'a pas été révélée, torpillant le dit intérêt. Donc :
- les responsables de ces projets ne peuvent même pas tracer les vulnérabilités dans leur processus de validation,
- les utilisateurs de ces projets ne savent pas qu'ils devraient changer, ne serait-ce que temporairement.

On jurerait une couverture pour une tentative de la NSA d'introduire des logiciels espion partout si ce n'était pour le manque de discrétion.

Bref : des vulnérabilité partout, du temps perdu, et l'unique intérêt qu'on pourrait y trouver n'existe pas puisque les projets vulnérables sont tenus secrets. Je n'ai pas assez de mes deux mains pour applaudir.
16  0 
Avatar de ormond94470
Membre habitué https://www.developpez.com
Le 22/04/2021 à 14:21
Le plus intelligent aurait été d'en parler à un grand chef chez Linux sans qu'il le dise à ses collègues, de faire passer les tests de validité mais qu'ils suivent un processus parallèle ou la validité ou le refus ne change rien au code du noyau.

Aussi que le code fourni soit donné par un expert qui suivent les standard ce qui ne semble pas être le cas ici
14  0 
Avatar de kain_tn
Membre expert https://www.developpez.com
Le 22/04/2021 à 14:16
Citation Envoyé par Stéphane le calme Voir le message

« Greg,

« Je vous demande respectueusement de cesser et de vous abstenir de porter des accusations farfelues à la limite de la calomnie.

« Ces correctifs ont été envoyés dans le cadre d'un nouvel analyseur statique que j'ai écrit et sa sensibilité n'est évidemment pas excellente. J'ai envoyé des correctifs dans l'espoir d'obtenir des commentaires. Nous ne sommes pas des experts du noyau Linux et faire ces déclarations à plusieurs reprises est dégoûtant à entendre.
Elle est bien bonne, celle-là. Le gars se fait prendre la main dans le sac, et il vient encore faire sa pleureuse après

Citation Envoyé par Stéphane le calme Voir le message

Que pensez-vous de cette approche ?
La démarche est vraiment limite: ça fait perdre du temps à la communauté, et si le but est vraiment de faire de la recherche en sécurité (comprendre aider à sécuriser des logiciels et non pas les détruire), alors la moindre des choses c'est de prévenir de la tentative AVANT que le code ne passe dans une branche de production.

Ça rappelle les "chercheurs" qui trouvent des failles et qui publient la faille avant même d'avertir l'éditeur et de lui laisser le temps de corriger...

Citation Envoyé par Stéphane le calme Voir le message

Pensez-vous que l’attitude du chercheur était justifiée au nom de la science et de la sécurité ?
Je trouve les propos tels qu'ils sont rapportés dans l'article d'assez mauvaise foi (les propos, pas l'article). Du coup il m'est difficile d'être en accord avec la méthode employée. Quid des autres projets? Est-ce qu'ils se sont engagés à les prévenir?

Citation Envoyé par Stéphane le calme Voir le message

Ou pensez-vous que les responsables du noyau Linux avaient raison de les bannir du noyau, et que cette approche ne devrait pas être encouragée ?
Complètement. Ces mecs font perdre du temps en revue de code. De plus, si ces gens testent vraiment les processus de validation de code dans les projets Open Source, alors cette réponse est plus que justifiée puisqu'elle fait partie du processus.

C'est un peu comme les tests de Milgram, dans les années 60: les expériences étaient très discutables du point de vue éthique, du coup si un "cobaye" lui avait répondu violemment, il n'aurait eu aucun droit de s'en plaindre (pas d'un point de vue légal mais d'un point de vue éthique).
12  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 28/04/2021 à 9:16
C'est très borderline et limite illégal du moins du point de vue du droit français. Que l'intension soit bonne ou mauvaise ne change pas l'illégitimité de l'acte. Ils se sont fait gauler sur au moins certains correctifs douteux, il est donc logique que tous leurs correctifs soient considérés comme douteux.
9  0 
Avatar de archqt
Membre expérimenté https://www.developpez.com
Le 22/04/2021 à 12:24
L'approche est correcte. Mais cela fait perdre du temps au mainteneurs du noyaux donc...Mais comment faire autrement si le but recherché est de vérifier que les mainteneurs travaillent bien ?

Cela montre au moins qu'on ne rajoute pas des bugs facilement dans le noyau.
10  2 
Avatar de walfrat
Membre expérimenté https://www.developpez.com
Le 22/04/2021 à 14:35
Cette approche ne devrait simplement pas être encouragé car il serait facile pour n'importe qui de déclarer qu'il "teste" la communauté <XY>.

A la rigueur, il faudrait un circuit officiel qui permet de déclencher de temps en temps du testing. A bien encadrer afin que cela ne représente pas trop d'heures dédié à des fixs qui n'en sont pas.

Bien qu'on soit tous d'accord que c'est important, si on vous apprend que vous en avez chiez pendant un mois sur des fix de testing, vous allez le prendre très moyennement.

Après, si les chercheurs avaient demandé a des communautés si elles peuvent prendre le temps d'organiser un testing pour leur études, je suis pas certain qu'ils auraient vraiment trouver des volontaires fiable (au sens qui respectent la démarche et ne faussent donc pas les résultats).
7  0 
Avatar de kain_tn
Membre expert https://www.developpez.com
Le 26/04/2021 à 17:03
Citation Envoyé par micka132 Voir le message
Il me semble que le point le plus important c'est quand même de faire prendre conscience que l'open source peut être à double tranchant.
Des personnes mal intentionnée peuvent (et ne s'en privent sûrement pas) introduire des vulnérabilités.
Oui, tout comme le Closed-Source (rien que ces derniers mois, on a Ubiquiti, Microsoft Azure à travers Solar Winds Orion, puis Microsoft Exchange. les firewalls Zyxel et leur compte admin caché et codé en dur, et pas plus tard qu'aujourd'hui un article sur Clickstudios PasswordState).

L'Open-Source est tout aussi vulnérable, comme tu le soulignes, et tu as raison (d'ailleurs, il me semble que c'était un des postulats de l'article de recherche en question).

Du coup il est important de tirer parti d'un avantage de l'Open Source: auditer le code.

Après, il ne faut pas se le cacher, les audits ça coûte cher et les gens vraiment compétents ne courent pas les rues.
7  0 
Avatar de kain_tn
Membre expert https://www.developpez.com
Le 23/04/2021 à 23:00
J'ai pris le temps de lire l'article de recherche écrit par les deux thésards qui font polémique. Il est disponible ici, sur le Github d'un des deux étudiants.

En gros, les gars expliquent leur méthodologie. Ils ont analysé du code et des patchs sur plusieurs projets Open Source (Linux, Android, OpenSSL, etc), mais dans les faits la partie où ils ont soumis du code est limitée au noyau Linux.

Ils se sont concentrés sur l'introduction de UAF (Use After Free), parce que c'est facile à faire et difficile à contrôler, du fait de la complexité du code et de divers facteurs tels que les accès concurrents.

Ils précisent bien qu'aucun bug n'a été introduit dans le code. En gros ils ont toujours envoyé des emails pour annuler lorsque leur patch était accepté:
[...]
Note that the experiment was performed in a safe way—we ensure that our patches stay only in email exchanges and will not be merged into the actual code, so it would not hurt any real users (see §VI-A for details)[...]
[...]
All the UAF-introducing patches stayed only in the email exchanges, without even becoming a Git commit in Linux branches.[...]

Ils ont l'air aussi d'avoir essayé de ne pas stigmatiser les développeurs, ce que j'apprécie:
[...]
All of these emails are sent to the communities instead of individuals. We also prevent the linkage to maintainers. In particular, to protect the maintainers from being searched, we use a random email account[...]

Ils admettent aussi que leur recherche va prendre du temps aux développeurs du noyau.
[...]
The OSS communities are understaffed, and maintainers are mainly volunteers. We respect OSS volunteers and honor their efforts. Unfortunately, this experiment will take certain time of maintainers in reviewing the patches.[...]
Là où je trouve que leur article pêche un peu, c'est dans les propositions de solutions de mitigation:
  1. Modifier le code de conduite pour dire un truc du style "je m'engage à ne pas introduire de bugs de manière intentionnelle"
  2. Introduire un système de réputation des contributeurs et vérifier leur identité, malgré le fait que ce soit difficile
  3. Utiliser plus d'outils d'analyse statique malgré les faux positifs possibles
  4. Utiliser plus des outils d'analyse dynamique comme des fuzzers, sachant que le problème est de couvrir du code de drivers sans avoir forcément le matériel à disposition (et qu'il y a déjà un fuzzer utilisé par les développeurs du noyau)
  5. Accepter les patchs préventifis (c'est-à-dire qui ne corrigent pas de bugs mais qui corrigent des risques de failles potentielles)
  6. Augmenter le nombre de personnes qui reçoivent la demande de patch au lieu de se limiter à la liste des mainteneurs d'un module


Autant les points 2, 3 et 6 me paraissent plutôt pertinents, autant le point 1 par exemple relève du pur délire...

La bonne nouvelle c'est que toutes les vulnérabilités analysées sont liées à une mauvaise manipulation des ressources, et sont, je pense, en faveur de l'introduction de Rust dans le noyau. Et pour le coup, Rust a un réel avantage sur ce point.

Pour le reste de l'histoire, je pense qu'ils ont juste usé la patience de Greg Kroah-Hartman qui a craqué quand il a vu une énième soumission publiée, et qui s'est dit "Oh non, ils recommencent leurs expériences et ils vont nous faire perdre notre temps". C'est ce que je comprends de son message:
Citation Envoyé par Stéphane le calme Voir le message
[...]
« Maintenant, vous soumettez à nouveau une nouvelle série de correctifs manifestement incorrects, alors que suis-je censé penser d'une telle chose?

« De toute évidence, ils n'ont PAS été créés par un outil d'analyse statique qui est de toute intelligence, car ils sont tous le résultat de modèles totalement différents, et qui ne corrigent évidemment rien du tout. Alors, que suis-je censé penser ici, à part le fait que vous et votre groupe continuez à mener des expériences sur les développeurs de la communauté du noyau en envoyant des correctifs aussi absurdes ?
[...]

Pour ceux que ça intéresse, les résultats de cet article seront présentés lors du 42ème symposium sur la sécurité et la vie privée à Oakland, en mai 2021.
5  0 
Avatar de kain_tn
Membre expert https://www.developpez.com
Le 22/04/2021 à 14:28
Citation Envoyé par ormond94470 Voir le message
Le plus intelligent aurait été d'en parler à un grand chef chez Linux sans qu'il le dise à ses collègues, de faire passer les tests de validité mais qu'ils suivent un processus parallèle ou la validité ou le refus ne change rien au code du noyau.

Aussi que le code fourni soit donné par un expert qui suivent les standard ce qui ne semble pas être le cas ici
Oui.

D'ailleurs, l'université du Minnesota elle-même semble penser que ses chercheurs n'ont pas agit de manière éthique:
Citation Envoyé par Stéphane le calme Voir le message

L'université du Minnesota, quant à elle, a publié le communiqué suivant :

« Les dirigeants du département d'informatique et d'ingénierie de l'Université du Minnesota ont appris aujourd'hui les détails de la recherche menée par l'un de ses membres du corps professoral et des étudiants diplômés sur la sécurité du noyau Linux. La méthode de recherche utilisée a soulevé de sérieuses préoccupations dans la communauté du noyau Linux et, à partir d'aujourd'hui, cela a abouti à l'interdiction de l'Université de contribuer au noyau Linux.

« Nous prenons cette situation très au sérieux. Nous avons immédiatement suspendu cette ligne de recherche. Nous étudierons la méthode de recherche et le processus par lesquels cette méthode de recherche a été approuvée, déterminerons les mesures correctives appropriées et nous protégerons contre les problèmes futurs, si nécessaire. Nous rendrons compte de nos résultats à la communauté dès que possible ».
4  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 22/04/2021 à 22:07
Je rejoins les autres membres du forum, l'agissement de ces chercheurs est une perte de temps et j'en viens a penser que c'est une attaque envers l'open source, qui serait plus ouvert a l'ajout de code malicieux.
Deux choses qui n'ont pas ete mentionnees et qui me paraissent interessantes :
  • pour une etude parue en fevrier, pourquoi ils n'ont pas immediatement revert leur code le jour apres publication ? L'etude etant finie, autant revert le mal qu'ils ont fait au code ?
  • l'etude parle de l'open source. Mais au final, cela ne veut pas dire que les logiciels open source sont plus faillibles/attaquable de la sorte que les autres. On pourrait tres faire une etude, plus longue certes, ou le chercheur se fait recruter par une entreprise et commence a commiter du code malicieux. D'ailleurs, cela me rappelle la news recente d'une fuite de donnees qui, selon l'entreprise concernee, cela sera de la faute d'un stagiaire...

En bref, a premiere vue (je n'ai pas lu le papier), l'etude n'apporte pas grand chose et ca fait perdre du temps.

EDIT: vu la conclusion du papier (rapide a lire), je ne vois aucun argument qui ne s'appliqueraient pas a une entreprise... Aussi, la communaute aurait donnee un feedback quant a l'etude, mais cette section ne contient aucun reference.
4  0