Discussion :

[Stéphane le calme]

Des chercheurs de l'université du Minnesota ont secrètement tenté d'ajouter des vulnérabilités au noyau Linux
et ont fini par être bannis

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 ?

[archqt]

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.

[BugFactory]

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.

[phil995511]

Avec la NASA qui veut avoir la main sur tout et les Chinois qui ne se comportent pas mieux, il va falloir commencer à choisir avec grand soins qui prendre dans ses équipes de développement...

[kain_tn]

« 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

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...

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?

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).

[ormond94470]

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

[kain_tn]

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:

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 ».

[walfrat]

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).

[Aurelien.Regat-Barrel]

Voilà qui ne va pas améliorer le rapport entre les dev et les experts en sécurité.

Déjà que certains se font les experts de l'embuscade sur chaque bug report qui tombe histoire d'appuyer encore plus là où ça fait mal. Mais si en plus ils se mettent à tendre des pièges... à mon avis ils ont rien compris à comment on fait pour améliorer un système. On ne tire aucune autorité (au sens noble : être respecté et suivi pour ses actions) à se comporter en schtroumpf à lunettes. C'est en posant des actes qui améliorent les choses qu'on peut inspirer les autres et initier un changement.

Avec la NASA qui veut avoir la main sur tout

La NASA, tu es sûr ?

[Canvas]

Le document de recherche dont il est question : On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits.

L'adjectif hypocrite est de circonstance.

[LittleWhite]

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.

[bouye]

La méthodologie de la recherche est plutôt d'une morale douteuse mais au moins ils ont publié leur papier. Cependant il ne faut pas non plus se voiler la face : ce qu'ils ont tenté de faire est probablement ce d'autres groupes tels que les principaux services de renseignements ou de contre-espionnage ou encore certains groupes de pirates / hackers ou mafieux doivent tenter de faire chaque jour pour intégrer des failles et vulnérabilité a leurs avantages dans des projets OpenSource. Si on peut espérer que, sur des projets de petite ampleur, chaque contributeur œuvre de manière "optimiste", pour le bien commun et l’amélioration positive du projet, il est illusoire que croire que ça reste le cas lorsque le projet a atteint une certaine masse critique de contributeurs ou entités contributrices dont la plupart ne se connaissent pas les uns les autres.

[kain_tn]

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:

[...]
« 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.

[LittleWhite]

J'ai pris le temps de lire l'article de recherche écrit par les deux thésards qui font polémique.

+1 pour avoir pris le temps de le lire.
Je tiens à préciser, pour ceux pour qui un article scientifique pourrait faire peur, qu'il ne faut pas hésiter à lire un article scientifique. Ce n'est pas difficile, l'anglais n'est généralement pas compliqué et c'est souvent intéressant. Bref, lancez-vous .

[Patrick Ruiz]

Linux : Greg Kroah-Hartman refuse les excuses via lettre ouverte des chercheurs impliqués dans le scandale des « commits hypocrites »
Ou d’introduction secrète de vulnérabilités au noyau

En général, les soumissions de correctifs à l’équipe de mainteneurs du noyau Linux ont pour but de l’améliorer. Une équipe de chercheurs de l’université du Minnesota s’est mise en marge de ce schéma classique. Elle a plutôt procédé à la soumission furtive de patchs contenant des failles de sécurité cachées afin d’obtenir une mesure scientifique de la probabilité que ceux-ci soient acceptés et fusionnés. Elle s’excuse désormais quant à l’approche adoptée puisque sous le coup d’un bannissement.

Le contenu de la lettre

Notre objectif était d'identifier les problèmes liés au processus d'application des correctifs et les moyens de les résoudre et nous sommes désolés que la méthode utilisée dans l'article sur les "commits hypocrites" ait été inappropriée. Comme de nombreux observateurs nous l'ont fait remarquer, nous avons commis une erreur en ne trouvant pas le moyen de consulter la communauté et d'obtenir sa permission avant de réaliser cette étude ; nous l'avons fait parce que nous savions que nous ne pouvions pas demander la permission aux mainteneurs de Linux, sinon ils seraient à l'affût des correctifs soumis dans le cadre de notre étude. Bien que notre objectif était d'améliorer la sécurité de Linux, nous comprenons maintenant qu'il était blessant pour la communauté d'en faire un sujet de recherche et de gaspiller ses efforts en examinant ces correctifs à son insu et sans sa permission.

Nous voulons simplement que vous sachiez que nous ne ferions jamais de mal de façon intentionnelle à la communauté du noyau Linux et que nous n'introduisons jamais de failles de sécurité. Notre travail a été mené avec les meilleures intentions du monde et consiste à trouver et à corriger les failles de sécurité... Nous sommes une équipe de recherche dont les membres consacrent leur carrière à l'amélioration du noyau Linux. Nous nous efforçons de trouver et de corriger les vulnérabilités de Linux depuis cinq ans...

L'incident actuel a provoqué une grande colère dans la communauté Linux envers nous, l’équipe de recherche et l'Université du Minnesota. Nous nous excusons sans condition pour ce que nous reconnaissons maintenant comme une violation de la confiance partagée dans la communauté open source et nous demandons pardon pour nos faux pas. Nous cherchons à reconstruire la relation avec la Fondation Linux et la communauté Linux à partir d'un lieu d'humilité afin de créer une fondation à partir de laquelle, nous l'espérons, nous pourrons à nouveau contribuer à notre objectif commun d'améliorer la qualité et la sécurité des logiciels Linux... Nous nous engageons à suivre les meilleures pratiques en matière de recherche collaborative en consultant les dirigeants et les membres de la communauté sur la nature de nos projets de recherche, et en nous assurant que notre travail répond non seulement aux exigences de l'Institutional Review Board mais aussi aux attentes que la communauté nous a exprimées à la suite de cet incident.

Bien que cette situation ait été douloureuse pour nous aussi et que nous soyons sincèrement désolés pour le travail supplémentaire que la communauté du noyau Linux a entrepris, nous avons tiré de cet incident des leçons importantes sur la recherche avec la communauté open source. Nous pouvons faire mieux et nous le ferons et nous pensons que nous avons beaucoup à apporter à l'avenir et nous travaillerons dur pour regagner votre confiance.

L’équipe de chercheurs insiste : pas de vulnérabilités introduites au kernel

Ces chercheurs ont soumis des correctifs qui n’introduisaient pas de vulnérabilités, d'après leur lettre ouverte. « Ce travail n'a pas introduit de vulnérabilités dans le code Linux. Les trois correctifs incorrects ont fait l'objet de discussions et ont été bloqués lors d'échanges sur un forum de discussion Linux. Ils n'ont jamais été intégrés au code. Nous avons communiqué les résultats et nos conclusions (à l'exception des correctifs incorrects) de ce travail à la communauté Linux avant la soumission du document, nous avons recueilli leurs commentaires et nous les avons inclus dans l'article », indique-t-elle.

Greg Kroah-Hatman soumet le retour de l’équipe à conditions

Merci pour votre réponse. Comme vous le savez, la Fondation Linux et le conseil consultatif technique de la Fondation Linux ont soumis une lettre vendredi à votre université décrivant les actions spécifiques qui doivent être entreprises pour que votre groupe, et votre université, puissent travailler à regagner la confiance de la communauté du noyau Linux. Jusqu'à ce que ces actions soient entreprises, nous n'avons plus rien à discuter sur ce sujet. Merci

Sources : lkml1, lkml2

Et vous ?

Les chercheurs auraient-ils pu procéder autrement si le but recherché était de vérifier que les mainteneurs travaillent bien ? Si oui, comment ?

Voir aussi :

Canonical publie Ubuntu 19.10 Eoan Ermine avec GNOME 3.34, le support de Raspberry Pï 4 et le support expérimental du système de fichiers ZFS

Sortie de la version 5.4 du noyau Linux avec l'ajout d'un mode de verrouillage du noyau, d'une couche de sécurité pour détecter les modifications de fichiers et plusieurs autres améliorations

Ubuntu 19.04 (Disco Dingo) est publié avec la version 5.0 du noyau Linux et est plutôt perçu comme une mise à jour qu'une version majeure

Microsoft rend son système de fichiers exFAT open source et soutien l'intégration de cette technologie au noyau Linux afin de faciliter l'interopérabilité entre Linux et Windows 10

[kain_tn]

Ces chercheurs ont soumis des correctifs qui n’introduisaient pas de vulnérabilités, d'après leur lettre ouverte.

Ce n'est pas tout-à-fait vrai. Selon leur article de recherche, le but de tous leurs correctifs était d'introduire des vulnérabilités, afin de voir si elles étaient détectées.

Ce qui fait qu'aucune vulnérabilité n'est introduite c'est qu'ils ont soumis leurs patchs par email uniquement, et qu'ils ont pris contact avec les mainteneurs dans le cas des patchs acceptés (chose rendue possible du fait d'un délai entre l'acceptation et l'inclusion du patch au code source du noyau, comme ils l'expliquent dans leur article).

[Invité]

Ce n'est pas parce que Linux est un projet "libre" (les guillemets ont leur importance) qu'on peut mener des recherches en sécurité sans avoir obtenu aucun accord au préalable, même si ces dernières sont utiles à la communauté.

Si ces chercheurs avaient fait de même dans une entreprise privée, cela se serait soldé en poursuites pénales avec dommages et intérêts à la clé. Blacklister l'Université du Minnesota est une sanction gentille en comparaison.

[Uther]

Ce n'est pas tout-à-fait vrai. Selon leur article de recherche, le but de tous leurs correctifs était d'introduire des vulnérabilités, afin de voir si elles étaient détectées.

Ce qui fait qu'aucune vulnérabilité n'est introduite c'est qu'ils ont soumis leurs patchs par email uniquement, et qu'ils ont pris contact avec les mainteneurs dans le cas des patchs acceptés (chose rendue possible du fait d'un délai entre l'acceptation et l'inclusion du patch au code source du noyau, comme ils l'expliquent dans leur article).

C'était le but des patchs soumis dans le cadre de l'article.

Mais Greg Kroah-Hartman a décidé de retirer tous les patchs soumis par toutes les adresses mail en provenance de leur université, ce qui comprend une grosse majorité de vrai correctifs.

[kain_tn]

C'était le but de patchs soumis dans le cadre de l'article.

Mais Greg Kroah-Hartman a décidé de retirer tous les patchs soumis par toutes les adresses mail en provenance de leur université, ce qui comprend une grosse majorité de vrai correctifs.

Tout à fait. Je réagissais sur la phrase "Ces chercheurs ont soumis des correctifs qui n’introduisaient pas de vulnérabilités, d'après leur lettre ouverte", qui va à l'encontre de ce qu'ils décrivent dans leur article: c'est-à-dire que c'est le mode opératoire que les chercheurs ont suivi qui fait qu'il n'y a pas de vulnérabilités, et non pas le contenu de leurs patchs.

Pour le reste, oui, c'est bien ce que j'avais compris: Kroah-Hartman veut supprimer toutes les contributions de l'université du Minnesota, et pas seulement celles de ces trois chercheurs.

[micka132]

Les chercheurs auraient-ils pu procéder autrement si le but recherché était de vérifier que les mainteneurs travaillent bien ? Si oui, comment ?

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.
Que les mainteneurs ne les voient pas ne fait pas forcement d'eux de mauvais travailleurs.