URL:     https://linuxfr.org/news/retour-sur-l-affaire-des-patchs-hypocrites-de-l-universite-du-minnesota
Title:   Retour sur l’affaire des « patchs hypocrites » de l’Université du Minnesota
Authors: gouttegd
         Yves Bourguignon, volts, Ysabeau, Michaël, yPhil, seveso, orfenor, Benoît Sibaud, Gil Cot, cosmocat, pulkomandy, Arkem, palm123, Xavier Teyssier, tisaac, Nils Ratusznik et eggman
Date:    2021-04-23T19:25:10+02:00
License: CC By-SA
Tags:    noyau_linux, éthique, recherche_scientifique et cybersécurité
Score:   11


Le 6 avril 2021, [un patch](https://lore.kernel.org/linux-nfs/20210407001658.2208535-1-pakki001@umn.edu/) était posté sur la liste de discussion des développeurs du noyau Linux (LKML). Écrit par Aditya Pakki, un doctorant de l’Université du Minnesota, ce patch, en apparence trivial (trois lignes) et franchement indistinguable des milliers d’autres qui s’échangent sur la LKML, allait _in fine_ provoquer quinze jours plus tard [le bannissement](https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/) de toutes les contributions au noyau en provenance de l’Université du Minnesota.



Que s’est-il passé au juste ?

----

[Lignes de conduite de Linux à destination des chercheurs](https://github.com/torvalds/linux/commit/f09f6f9b69821c9efcf16e6b5b466ce9e263ca51)

----

# Le détail des faits



## Été 2020



L’histoire commence en fait l’été précédent, lorsque cinq patchs distincts sont soumis aux développeurs du noyau.


* Le 4 août 2020, un dénommé « James Bond » propose [un patch](https://lore.kernel.org/lkml/20200804183650.4024-1-jameslouisebond@gmail.com/) supposé corriger une fuite de mémoire. Le patch est ignoré.


* Le 9 août 2020, le même « James Bond » propose [un autre patch](https://lore.kernel.org/lkml/20200809221453.10235-1-jameslouisebond@gmail.com/) aussi supposé corriger une fuite de mémoire. Le patch est [rejeté d’emblée](https://lore.kernel.org/lkml/dd4ac5db-9ae7-fbf7-535b-c0d3fa098942@kernel.org/) le lendemain, le problème qu’il était supposé corriger n’en étant pas un.



* Le 20 août 2020, un dénommé « George Acosta » propose [un patch](https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.ubuntu@gmail.com/) supposé corriger un problème avec un compteur de références. Le patch [est rejeté](https://lore.kernel.org/lkml/20200821081449.GI5493@kadam/) le jour même, non que le problème n’en soit pas un mais la correction proposée n’est pas bonne.



* Aussi le 20 août, le même « George Acosta » propose [un autre patch](https://lore.kernel.org/lkml/20200821031209.21279-1-acostag.ubuntu@gmail.com/) pour que le noyau envoie un message dans les journaux du système lorsqu’une certaine condition d’erreur se présente. Le patch est [accepté](https://lore.kernel.org/lkml/20200828071931.GB28064@gondor.apana.org.au/) une semaine plus tard et intégré dans la branche de développement de Herbert Xu, un des mainteneurs du sous-système « crypto » du noyau.



* Le 21 août, « James Bond » à nouveau propose [un patch](https://lore.kernel.org/lkml/20200821070537.30317-1-jameslouisebond@gmail.com/) supposé corriger un comptage de référence. Une semaine plus tard, un développeur noyau [suggère](https://lore.kernel.org/lkml/20200827144600.2ec7c4ab@xps13/) une meilleure approche, ce à quoi « James Bond » [répond](https://lore.kernel.org/lkml/CAPKyc-si2e2-9RDgLBO4Ox0wX5fr+NjSM_Noih_Pay+trNzndQ@mail.gmail.com/) qu’après vérification, il s’est rendu compte que son patch est inutile de toute façon.



Ces patchs n’ont rien de vraiment remarquable, si ce n’est l’utilisation évidente de pseudonymes par leurs auteurs (George Acosta est le nom d’un footballeur américain, et faut-il réellement préciser que « James Bond » est le nom d’un personnage de fiction ?), quelque chose d’assez inhabituel sur la LKML — les développeurs du noyau postent généralement sous leur vrai nom, comme sur beaucoup d’autres listes liées au logiciel libre en fait. Quoi qu’il en soit, rien à l’été 2020 ne permet de soupçonner que ces patchs cachent quelque chose.


## Annonce du papier “hypocrite commits”



En novembre 2020, Qiushi Wu et Kangjie Lu, deux chercheurs de l’Université du Minnesota (respectivement doctorant et professeur, le premier faisant sa thèse sous la direction du second), annoncent qu’un de leurs articles, appelé “_On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits_”, a été accepté pour présentation au [42ᵉ Symposium de l’IEEE sur la sécurité et la vie privée](https://www.ieee-security.org/TC/SP2021/index.html) (« S&P 2021 »). L’annonce est faite sur Twitter dans un tweet depuis supprimé, mais [conservé](https://web.archive.org/web/20201121180249/https://twitter.com/kengiter/status/1330209964812607494) par Internet Archive.


À ce moment-là, l’article n’est pas encore publiquement disponible. Au-delà de ses auteurs, seuls les relecteurs du comité d’organisation du symposium S&P 2021 ont eu accès au texte intégral. N’est publiquement disponible que le résumé (_abstract_), visible dans la copie d’écran de la première page de l’article telle qu’elle figure dans le tweet d’annonce.



Le résumé permet de comprendre que cet article, qu’on appellera par la suite et dans le reste de cette dépêche le _hypocrite commits paper_ (« papier sur les commits hypocrites »), s’intéresse à la possibilité pour un attaquant d’introduire une vulnérabilité dans un logiciel libre, via la voie normale de soumission de patchs, en misant sur la complexité du logiciel libre ciblé. En quelques mots, le principe est de proposer un patch très simple, de quelques lignes seulement et qui, à première vue, ne fait que corriger un bug mineur — mais qui, en réalité introduit aussi une vulnérabilité dans une autre partie du code. Le pari de l’attaquant est que les développeurs en charge de relire le patch proposé ne réaliseront pas son impact réel, caché par la complexité de la base de code. C’est ce que Qiushi Wu et Kangjie Lu entendent par « commit hypocrite ».



Surtout, le résumé mentionne que les auteurs ont démontré la faisabilité d’introduire des vulnérabilités via des commits hypocrites, en prenant le noyau Linux comme exemple :



> As a proof of concept, we successfully introduce multiple exploitable use-after-free in the latest Linux kernel (in a safe way).



(« Comme preuve de concept, nous sommes parvenus à introduire plusieurs vulnérabilités de type _use-after-free_, exploitables, dans le dernier noyau Linux (de façon sûre). »)



Comme seul le résumé est disponible, il est impossible en novembre 2020 de savoir ce que les chercheurs ont fait exactement, ou d’établir un lien avec les patchs de « James Bond » et « George Acosta » mentionnés ci-dessus. Mais en l’absence de détails, la perspective d’un noyau Linux rendu délibérément vulnérable par des chercheurs dans le seul but de démontrer leur approche suscite immédiatement un certain émoi, et plusieurs personnes interpellent Kangjie Lu sur Twitter suite à son annonce.



Parmi elles, Sarah Jamie Lewis, cryptologue et directrice de l’[Open Privacy Research Society](https://openprivacy.ca/), [pointe particulièrement du doigt](https://twitter.com/SarahJamieLewis/status/1330618919376228352) les problèmes éthiques liés à l’expérimentation sur des sujets humains (les sujets étant ici les développeurs du noyau). En décembre, elle se joint à [Morten Linderud](https://linderud.dev/) (membre de l’équipe sécurité d’Arch Linux), [Santiago Torres-Arias](https://www.cerias.purdue.edu/site/people/faculty/view/3153) (professeur à l’Université de Purdue), et [René Mayrhofer](https://www.mayrhofer.eu.org/) (professeur à l’Université de Linz et ancien directeur de l’équipe sécurité d’Android chez Google), pour adresser [une lettre ouverte](https://hackmd.io/s/BJGs6Tfiw) au comité d’organisation du Symposium S&P 2021. Outre les considérations éthiques déjà mentionnées sur Twitter, le courrier pointe également les risques que l’expérience des « commits hypocrites » fait peser non seulement sur la sécurité du noyau Linux (si des failles ont bien été introduites comme le résumé le prétend ouvertement) mais aussi plus généralement sur les relations entre les développeurs de logiciels libres et le monde académique. Pour ces raisons, il est demandé au comité de revenir sur sa décision d’accepter la présentation du papier lors du symposium. Ce courrier restera sans réponse.



## Novembre-décembre 2020, début du rétro-pédalage



Quelques jours à peine après l’annonce du papier, les auteurs commencent à réagir sur Twitter aux critiques qui leur sont adressées. Le 22 novembre par exemple, Kangjie Lu [affirme](https://twitter.com/kengiter/status/1330649965270589441) que “_no bug was ever merged into code_”. Le lendemain, le tweet d’annonce [est supprimé](https://twitter.com/kengiter/status/1330669761219465218) et Kangjie promet des « éclaircissements » à venir. À partir de là les deux auteurs ne répondent plus à aucune sollicitation sur Twitter concernant leur papier.



Les « éclaircissements » promis arrivent le 15 décembre, dans [une FAQ](https://www-users.cs.umn.edu/%7Ekjlu/papers/clarifications-hc.pdf) publiée sur la page personnelle de Kangjie Lu sur le site de l’Université du Minnesota. Les chercheurs y affirment clairement « n’avoir jamais introduit, ni avoir eu l’intention d’introduire, le moindre bogue ou la moindre vulnérabilité dans le noyau Linux » — en flagrante contradiction avec ce qu’ils affirmaient dans le résumé de leur article un mois plus tôt.



Selon cette FAQ, la procédure suivie par les chercheurs durant leur preuve de concept était la suivante :



1. le chercheur soumet un patch hypocrite aux développeurs du noyau sur la LKML ;
2. un développeur noyau annonce que le patch lui semble bon et qu’il va donc l’intégrer ;
3. le chercheur répond alors immédiatement avec un message du genre « non attendez, je viens de me rendre compte que ce patch introduit un problème ailleurs, ne l’intégrez pas ».


Cette procédure, expliquent les auteurs, garantit donc qu’à aucun moment les patchs hypocrites ne sont intégrés dans une branche quelconque du noyau Linux, encore moins dans la branche de Linus et donc dans une version publiée. Ils expliquent également que la procédure a concerné au total trois patchs hypocrites, et qu’à chaque fois les développeurs du noyau ont bien confirmé n’avoir pas intégré le patch.



À ce stade-là toutefois, ni les patchs en question ni les pseudonymes utilisés par les chercheurs ne sont encore dévoilés, donc il n’y a encore aucun moyen pour les développeurs du noyau (ou pour qui que ce soit d’autre d’ailleurs) de vérifier les dires des chercheurs.



## Publication du pre-print



Au cours du premier trimestre 2021, un [pre-print](https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf) du papier “hypocrite commits” est publié par Qiushi Wu sur son compte GitHub. La date exacte de publication est inconnue (en tout cas je ne l’ai pas trouvée), mais le PDF est daté du 10 février.



## Avril 2021, l’affaire éclate



En avril 2021, Additya Pakki, doctorant dans l’équipe de Kangjie Lu à l’Université du Minnesota, commence à proposer plusieurs patchs supposés corriger des bugs qui auraient été détectés par l’analyseur de code qu’il développe dans le cadre de sa thèse. Ces patchs sont de qualité douteuse et [l’un d’eux](https://lore.kernel.org/lkml/20210407001658.2208535-1-pakki001@umn.edu/), le 6 avril, va être la proverbiale goutte d’eau qui fait déborder le vase. Après que [plusieurs](https://lore.kernel.org/lkml/20210407153458.GA28924@fieldses.org/) [développeurs](https://lore.kernel.org/lkml/c0de0985c0bf09a96efc538da2146f86e6fa7037.camel@hammerspace.com/) eurent pointé que le problème supposément corrigé par le patch n’en était pas un, Greg Kroah-Hartman, responsable de la branche `-stable` du noyau, [accuse ouvertement](https://lore.kernel.org/lkml/YH5%2Fi7OvsjSmqADv@kroah.com/) Additya Pakki, le 20 avril, de soumettre délibérément des patchs qu’il sait incorrects, ce qui n’est pas sans provoquer l’étonnement d’autres développeurs noyau qui n’étaient pas forcément au courant de l’histoire autour du papier « hypocrite commits » :



> > > _(Greg Kroah-Hartman, répondant à Additya Pakki)_ Merci d’arrêter de soumettre des patchs que vous savez incorrects. Votre professeur a d’étranges manières d’obtenir un papier en abusant du processus de relecture des patchs.
>
> > _(Bruce Fields, mainteneur de NFS)_ C’est quoi cette histoire ?
>
> _(Leon Romanovsky, développeur embarqué)_ Ces patchs font partie de ce projet de recherche : https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf
>
> Ils introduisent des bogues dans le noyau délibérément. Hier, j’ai jeté un œil à quatre patchs d’Additya qui ont été acceptés et trois d’entre eux ajoutaient des « trous » de sécurité d’une manière ou d’une autre.


Les échanges entre Additya Pakki et Greg Kroah-Hartman dégénèrent rapidement, le premier accusant le second de diffamation et reprochant à la communauté des développeurs noyau d’être hostile aux nouveaux-venus. La [réponse de Greg Kroah-Hartman](https://lore.kernel.org/lkml/YH%2FfM%2FTsbmcZzwnX@kroah.com/) le 21 avril, dans laquelle il annonce le rejet préventif de toutes les contributions en provenance de l’Université du Minnesota _et_ le retrait de toutes les contributions antérieures, va faire le tour du web :



> Vous et votre équipe de recherche avez publiquement reconnu avoir soumis des patchs bogués en connaissance de cause, juste pour tester la réaction des développeurs noyau. Vous avez carrément publié un papier là-dessus.
>
> Voilà maintenant que vous soumettez à nouveau un ensemble de patchs dont il est évident qu’ils sont incorrects. Qu’est-ce que je suis censé en conclure ?
>
> […]
>
> Notre communauté n’apprécie guère d’être traitée comme un sujet d’expériences, et d’être « testée » par quelqu’un qui soumet délibérément des patchs qui ne servent à rien ou, pire, qui introduisent des bogues.
>
> […]
>
> En conséquence, je vais maintenant devoir bannir toutes les contributions en provenance de votre Université, et dégager toutes vos contributions précédentes, puisqu’il est clair qu’elles ont été soumises de mauvaise foi dans l’intention de causer des problèmes.


À partir de là, les choses vont aller très vite (sauf sur LinuxFR.org). Le même 21 avril, Greg Kroah-Hartman envoie [une première liste](https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/) de 190 patchs soumis par des contributeurs avec une adresse en `@umn.edu` et préalablement acceptés, afin qu’ils soient revus à nouveau et annulés (_reverted_) si besoin.



Dans le même temps, l’utilisateur _neoflame_ sur Hacker News [annonce](https://news.ycombinator.com/item?id=26895209) avoir probablement identifié les trois patchs hypocrites décrits dans le papier : il s’agit des deux patchs de « George Acosta » du 20 août 2020, et du patch de « James Bond » du 9 août. Cette découverte met en évidence deux choses :



* deux des trois patchs ont été rejetés d’emblée par les développeurs noyau, et le troisième n’introduit _pas_, en réalité, de vulnérabilité — autrement dit, la « preuve de concept » avancée par les chercheurs, sensée démontrer la faisabilité d’introduire des vulnérabilités dans un logiciel libre en trompant la vigilance des mainteneurs… a échoué à faire exactement ça (un « détail » que les chercheurs n’ont pas jugé utile de mentionner) ;
* les chercheurs ont utilisé des pseudonymes avec des adresses non-affiliées à l’Université du Minnesota (un autre « détail » qui n’apparaît pas dans le papier).



Ce dernier point signifie notamment que les développeurs noyau ne peuvent pas se fier aux adresses associées aux patchs, que ce soit pour identifier tous les patchs hypocrites déjà soumis ou pour bloquer toute nouvelle tentative de soumettre de tels patchs.



## Investigations et résolution



En quelques jours, l’affaire n’est plus cantonnée aux listes de discussion du noyau Linux, et remonte au « niveau supérieur » chez les deux parties. Du côté des chercheurs, la direction du département _Computer Science & Engineering_ (CS&E) de l’Université du Minnesota [annonce](https://cse.umn.edu/cs/statement-cse-linux-kernel-research-april-21-2021) le 21 avril avoir suspendu les travaux de recherche concernés et promet une investigation. Du côté du noyau, le _Technical Advisory Board_ de la _Linux Foundation_ [s’empare du dossier](https://lore.kernel.org/lkml/202104221451.292A6ED4@keescook/) le 22 avril.



Le 23 avril, la _Linux Foundation_ [demande formellement](https://drive.google.com/file/d/1bUsiJQesI4pCioE6h4ZUOghg0qHpemcb/edit) à l’Université du Minnesota de :



* divulguer les détails permettant d’identifier _tous_ les patchs hypocrites soumis par les chercheurs de l’université dans le cadre de _tous_ leurs travaux, sur _tous_ les projets libres ciblés (et pas seulement le noyau Linux, si jamais d’autres projets ont aussi fait l’objet d’expérimentations similaires) ;
* rétracter le « papier des commits hypocrites », et tout autre papier ou présentation résultant des mêmes pratiques ;
* garantir que tous les futurs projets de recherche de l’université impliquant des personnes ne pourront démarrer qu’_après_ avoir été dûment validés par le comité d’éthique (_Institutional Review Board_, IRB) de l’université ;
* garantir que ces mêmes projets ne seront possibles qu’avec le consentement explicite des personnes impliquées dans l’expérience.



La réponse de l’Université du Minnesota se fait en trois temps.


1.  Le 26 avril, Qiushi Wu et Kangjie Lu contactent les organisateurs du symposium S&P 2021 pour [demander la rétractation](https://www-users.cs.umn.edu/~kjlu/papers/withdrawal-letter.pdf) de leur papier.
1.  Le lendemain, ils publient leur [« full disclosure »](https://www-users.cs.umn.edu/~kjlu/papers/full-disclosure.pdf), révélant pour la première fois _quels_ sont les « patchs hypocrites » de leur expérience. Ce document confirme essentiellement les découvertes de l’utilisateur _neoflame_ mentionnées ci-dessus. Ce sont les cinq patchs évoqués au début de cette dépêche. Comme on l’a vu, un seul de ces patchs a été accepté par les développeurs du noyau. Ce patch était supposé être un « patch hypocrite », mais s’est avéré en réalité être un patch valide, n’introduisant aucune vulnérabilité. Les quatre autres patchs ont été rejetés ou ignorés. Tous les autres patchs jamais envoyés par des chercheurs de l’université (dont ceux d’Additya Pakki, qui ont fait éclater l’affaire) ont été soumis de bonne foi, et aucun autre projet que le noyau n’a été visé.
1.  Le 27 avril, l’université [répond formellement](https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEiO9cUq/view) à la Linux Foundation.


En parallèle, les développeurs du noyau continuent le travail de révision de tous les patchs en provenance de l’Université du Minnesota, initié par Greg Kroah-Hartman le 21 avril. Ce travail s’achève le 5 mai, avec la [publication du rapport](https://lwn.net/ml/linux-kernel/202105051005.49BFABCE@keescook/) du _Technical Advisory Board_ de la Linux Foundation.



Au final, 442 patchs acceptés dans le noyau ont été revus (le rapport en donne la liste complète), dont ;


* 364 étaient corrects ;
* 39 étaient problématiques et ont nécessité une correction ;
* 27 étaient problématiques lors de leur soumission mais ont été corrigés ou retirés avant le début de l’affaire ;
* 12 étaient problématiques lors de leur soumission mais concernaient des parties du code qui ont depuis été retirés du noyau.



(Note : le rapport dit en résumé que 435 patchs ont été revus, mais donne une liste de 442 patchs ; les chiffres ci-dessus sont extraits de cette liste, pas du résumé — la liste a sans doute été mise à jour peu de temps avant la conclusion du rapport, sans que le résumé ne soit mis à jour en conséquence.)



# En quoi le « papier des commits hypocrites » est problématique ?



Ce n’est certes pas la première fois que des chercheurs en informatique se penchent sur le noyau Linux et sa sécurité. Normalement, l’intérêt des chercheurs pour le noyau est vu favorablement comme une opportunité d’améliorer ce dernier. Mais ici, les travaux de Qiushi Wu et Kangjie Lu sont problématiques, pour deux grosses raisons.



## Le « papier sur les commits hypocrites » est contraire à l’éthique


C’est *le* problème qui a sauté aux yeux de toute la communauté, dès l’annonce du papier — mais qui est initialement passé inaperçu des chercheurs, du comité d’éthique  (_Institutional Review Board_ ou IRB, dans le jargon académique américain) de l’Université du Minnesota, et du comité d’organisation du symposium S&P2021.



### Manquements à l’éthique des recherches impliquant des sujets humains



Des « recherches impliquant des sujets humains » ? Pour un papier dont le sujet est un composant logiciel (le noyau Linux) ?



Eh bien oui ! Parce qu’en réalité, le sujet du « papier sur les commits hypocrites » n’est pas tant le noyau Linux lui-même que les personnes qui le développent — et qui, vérifications faites, sont bel et bien des êtres humains. La question à laquelle la preuve de concept décrite plus haut tente de répondre est bien « les _personnes_ qui reçoivent les patchs envoyés sur les listes de discussion du noyau, et qui décident d’accepter ou non ces patchs, peuvent-elles se laisser avoir par des patchs hypocrites ? » Ce n’est pas le _noyau_ qui accepte ou refuse un patch, mais bien ses développeurs et développeuses (à ce jour, aucune conscience autonome n’a encore émergé des sources du noyau — décevant, n’est-ce pas ?).


Or quand on veut réaliser des expériences sur des sujets humains, il y a des règles à respecter. Notamment, la participation des sujets à l’expérience doit être _volontaire_, ce qui implique qu’ils doivent être _informés_ de l’expérience et qu’ils _consentent_ à y participer.


Pour s’assurer du respect de ces règles, tout protocole expérimental impliquant des sujets humains doit être validé par un _comité d’éthique_, qui vérifie entre autres choses que le protocole prévoit bien l’information des participants et le recueil de leur consentement.


Ici, les chercheurs ont eux-mêmes reconnus, dans leur [FAQ de décembre 2020](https://www-users.cs.umn.edu/%7Ekjlu/papers/clarifications-hc.pdf) n’avoir pas initialement consulté le comité d’éthique de leur université, parce qu’il ne leur est jamais venu à l’esprit que leur travail constituait de la recherche sur des sujets humains (« nous étudions le _processus_ de relecture des patchs, pas les comportements individuels »). Ce n’est qu’après les remarques suscitées par le tweet d’annonce que les auteurs ont finalement sollicité _a posteriori_ l’avis de leur comité d’éthique, à la demande des organisateurs du symposium S&P2021.



On ne sait pas en quels termes les auteurs ont présenté leur projet au comité d’éthique. Mais celui-ci n’a apparemment pas tiqué à la seule mention du fait que les recherches avaient _déjà_ été effectuées (alors que c’est en soi une grosse violation des règles : la validation du protocole par un comité d’éthique doit toujours précéder les recherches !), et surtout a conclu que les travaux ne relevaient _pas_ de la recherche sur des sujets humains et en conséquence ne nécessitaient pas d’approbation de la part du comité.



Il semblerait, [d’après les organisateurs du symposium S&P2021](https://www.ieee-security.org/TC/SP2021/downloads/2021_PC_Statement.pdf), que les auteurs aient fourni à leur comité d’éthique une description très incomplète de leur expérience, ce qui pourrait expliquer la décision favorable rendue par ledit comité. (« Une relecture approfondie des documents du comité d’éthique ont révélé de possibles problèmes dans la description des expériences, et a conclu que les auteurs n’avaient pas fourni suffisamment de détails à leur comité d’éthique. ») Décider si cette « insuffisance de détails » est le fruit d’un regrettable oubli de la part des chercheurs ou bien d’une omission délibérée dans le but d’obtenir un avis favorable est laissé en exercice aux lectrices et lecteurs.



On se demandera quand même de quels détails le comité d’éthique pouvaient bien avoir besoin pour correctement qualifier ces travaux de recherches sur des sujets humains, quand nombres d’internautes (et pas des moindres, comme on l’a vu plus haut avec Sarah Jamie Lewis et les co-auteurs de sa [lettre ouverte](https://hackmd.io/s/BJGs6Tfiw) aux organisateurs du symposium S&P2021) avaient vu l’aspect humain sur la seule base du tweet d’annonce et de l’abstract du papier.


Quelle que soit la duplicité des chercheurs, ni le comité d’éthique de l’université (qui leur a donné un blanc-seing _a posteriori_) ni le comité d’organisation du symposium S&P2021 (qui a accepté le papier et a ignoré les remarques de la communauté jusqu’à ce que l’affaire ne devienne trop grosse pour être ignorée) ne se sont particulièrement illustrés dans cette affaire.


### Manquements aux règles du *pen-testing* et pratiques assimilées



Même si on accepte le point de vue initial des auteurs, selon lequel leurs travaux relèvent purement de la recherche en sécurité informatique et aucunement de la recherche sur des sujets humains, leur expérience n’est pas défendable. La recherche en sécurité informatique a aussi ses règles, et si elles ne sont peut-être pas autant codifiées que celles qui s’appliquent aux recherches humaines, elles n’en doivent pas moins être respectées.



Ici, deux règles au moins ont été violées :



* On n’attaque pas un système informatique dans le but de tester ou démontrer sa vulnérabilité sans l’accord express des responsables dudit système — ne serait-ce que pour éviter d’être poursuivi pour _piratage informatique_ !


* Si on découvre une faille, l’usage veut qu’elle soit dévoilée aux responsables du système préalablement à la publication (_responsible disclosure_).



### L’éthique, quelle importance ?



Possiblement le plus grave dans toute cette affaire, c’est à quel point elle révèle que tous les acteurs académiques impliqués se soucient autant de l’éthique que de leur première chaussette.



Dans le [communiqué des organisateurs du S&P2021](https://www.ieee-security.org/TC/SP2021/downloads/2021_PC_Statement.pdf), on apprend ainsi que :


> Le papier avait été relu par quatre relecteurs […] et avait reçu des notes très positives (2 scores « Accept » et 2 scores « Weak Accept », ce qui le plaçait dans le top 5 % de toutes les soumissions). […] Un membre du comité a brièvement mentionné un possible problème éthique dans son avis, mais ce commentaire ne suscita pas davantage de discussion à l’époque. Nous reconnaissons que nous sommes passés à côté.


Un « possible problème d’éthique », après tout c’est pas si grave, hein ? On ne va pas s’arrêter là-dessus, surtout pour un des meilleurs papiers qu’on ait reçus…


Dans leur [lettre ouverte à la communauté](https://cse.umn.edu/cs/open-letter-linux-community-april-24-2021), Kangjie Lu et ses collaborateurs écrivent :



> Comme de nombreux observateurs nous l’ont fait remarquer, nous avons fait une erreur en n’essayant pas de consulter la communauté [des développeurs du noyau] et d’obtenir sa permission avant de réaliser cette étude ; nous avons procédé ainsi parce que nous savions que nous ne pouvions pas demander une permission [de soumettre des patchs hypocrites] aux mainteneurs du noyau, car sinon ils auraient été sur leurs gardes.



Que les auteurs puissent écrire ça, en dit long sur ce qu’ils pensent de l’éthique. Ils considèrent clairement que quand l’éthique s’oppose à la bonne conduite d’un projet de recherche, c’est l’éthique qui doit céder : pas question de renoncer au projet ou d’essayer de trouver une autre approche au motif fallacieux que l’approche envisagé serait contraire à l’éthique.


Je ne pensais pas que cela devait être dit, mais : **en recherche, le respect des règles éthiques n’est pas optionnel !** Il n’est pas envisageable de ne respecter les règles éthiques que dans la mesure où elles ne vous contraignent pas trop.


Espérons que le premier « Atelier international sur l’éthique en sécurité informatique » ([EthiCS 2022](https://ethics-workshop.github.io/2022/)), qui doit se tenir cette année, fera progresser les choses. On regrettera tout de même que dans le comité d’organisation ne figurent que des spécialistes de la sécurité informatique et aucun spécialiste des questions éthiques, ce qui… encore une fois en dit long sur la place accordée à l’éthique dans le domaine, même dans un symposium supposément consacré à l’éthique !



Au moins l’un des deux présidents du comité d’organisation d’EthiCS 2022 aura une expérience personnelle à raconter, puisqu’il ne s’agit de personne d’autre que… Kangjie Lu, de l’université du Minnesota !


## Le « papier sur les commits hypocrites » est *frauduleux*



Ce problème est semble-t-il passé complètement inaperçu, éclipsé par le problème de manquements à l’éthique. C’est pourtant un problème majeur, qui suffit à lui seul à discréditer le papier et à justifier sa rétraction.



Dans ce papier, Qiushi Wu et Kangjie Lu formulent l’hypothèse qu’un attaquant peut introduire des failles de sécurité dans un logiciel libre par la voie normale de contribution à ce logiciel, en misant sur le fait que les développeurs se laisseront abuser par l’apparence faussement triviale de patchs « hypocrites » — des patchs qui prétendent corriger un problème mineur mais qui par effets de bord introduisent des vulnérabilités dans d’autres parties du code.



Pour appuyer leur hypothèse, ils réalisent pendant l’été 2020 une expérience « preuve de concept », dans laquelle ils soumettent cinq patchs « hypocrites » aux développeurs du noyau Linux. Comme on l’a vu plus haut, un seul de ces patchs a été accepté par les développeurs, et ce patch n’introduisait en réalité aucune vulnérabilité (les chercheurs croyaient ce patch hypocrite, ils ont par inadvertance écrit un patch légitime) ; les quatre autres patchs ont été soit ignorés, soit explicitement rejetés.



Les résultats de l’expérience sont donc sans appel : la « preuve de concept » ne supporte pas du tout l’hypothèse des chercheurs. Au contraire, elle tendrait plutôt à montrer que les développeurs de logiciel libre (ou, au moins, les développeurs du noyau Linux) sont vigilants et examinent soigneusement toutes les contributions, même les plus triviales, et sont de fait peu susceptibles de se laisser berner par des « patchs hypocrites ».



Qiushi Wu et Kangjie Lu auraient pu, et auraient dû, rapporter ces résultats dans leur papier. À la place, ils ont choisi de présenter leur expérience en oblitérant complètement le fait qu’elle avait échoué. Il n’est fait nulle mention du fait qu’ils n’ont en réalité _pas_ réussi à faire accepter un seul « patch hypocrite » dans le noyau. Au contraire, ils laissent clairement sous-entendre que l’expérience a été un succès :



> We *demonstrate* that it is practical for a malicious committer to introduce use-after-free bugs.



*Rien* dans le papier ne permet aux lecteurs de comprendre que l’expérience n’a pas produit le résultat claironné. Le seul moyen de s’en rendre compte est de consulter les archives des listes de discussion du noyau, mais la tâche n’est pas aisée puisque les patchs sont présentés dans le papier sans aucun contexte, aucune information permettant de trouver facilement le message d’origine (et donc la discussion subséquente) : seul le « corps » du patch est montré, comme dans cet exemple :



```
   pointerA = pointerC = malloc(...);
   ...
   pointerB = malloc(...);
   if (!pointerB) {
+      kfree(pointerA);
       return -ENOMEM;
   }
```













Ne sont mentionnés ni le nom d’emprunt sous lequel le patch a été soumis, ni la date, ni même le nom du fichier auquel le patch s’applique. Pour ne rien arranger, les auteurs précisent que le code a été « simplifié » pour être plus lisible.



Donc, quelqu’un souhaitant savoir si l’expérience a réussi devrait 1) identifier, dans les millions de lignes de code du noyau Linux, un bout ressemblant à celui présenté ; 2) trouver, parmi les milliers de patchs soumis sur les listes de discussions du noyau, celui qui touche ce bout de code pour introduire un changement semblable à celui présenté.



Rien que la première étape est déjà dantesque, et il est semble évident que les auteurs comptaient bien sur le fait que personne, à la lecture du papier, n’entreprendrait d’aller vérifier leurs dires. Il aura fallu attendre que l’affaire éclate, en avril 2021, pour que le dénommé _neoflame_ déjà mentionné ne décide que la tâche méritait qu’on s’y attelât… et ne découvre ainsi le pot aux roses.



En clair, en constatant l’échec de leur « preuve de concept », qui mettait à mal leur hypothèse selon laquelle les logiciels libres étaient vulnérables aux « patchs hypocrites », Qiushi Wu et Kangjie Lu ont décidé de présenter une conclusion que leurs observations n’étayent pas et de rendre le plus difficile possible toute vérification indépendante de leurs travaux, ce qui, dans le jargon académique, s’appelle du _bidonnage_, voire, une _fraude_.


Le comité d’organisation du symposium S&P2021, dans [le communiqué annonçant la rétraction du papier des commits hypocrites](https://www.ieee-security.org/TC/SP2021/downloads/2021_PC_Statement.pdf), s’attarde longuement sur les problèmes d’éthique du papier mais ne mentionne que très brièvement la fraude, en des termes très diplomatiques :



> Au cours de l’enquête, le comité d’organisation a aussi revu en détails les affirmations techniques du papier […] L’étude des patchs a montré que la description fournie par les auteurs dans leur papier était *ambiguë et dans certains cas trompeuse*. Les expériences ne fournissent pas de preuves concluantes pour soutenir les conclusions avancées par leurs auteurs […]


(Emphase ajoutée.)



# Le noyau Linux est-il vulnérable aux « commits hypocrites » ?



Le « papier des commits hypocrites » est donc un travail frauduleux réalisé en violation des règles éthiques. Si on met de côté ce _petit détail sans importance_, le papier nous apprend-il quelque chose sur le développement du noyau et sur sa sécurité ?



Avant de procéder à leur expérience, Qiushi Wu et Kangjie Lu ont d’abord réalisé un inventaire des failles de sécurité du noyau déjà connues (avec un numéro CVE attribué) et causées par des patchs de moins de trente lignes (le seuil arbitraire qu’ils ont fixé pour décider qu’un patch était « mineur »). Ils ont trouvé 138 failles causées par de tels patchs, qu’ils ont classifié en fonction de la nature de l’erreur à l’origine de la faille (déréférencement d’un pointeur non-initialisé, déréférencement d’un pointeur déjà libéré, dépassement de tampon, etc,).


Ces failles causées par des patchs mineurs représentent environ 10 % de toutes les failles qu’ils ont étudiées.


Bien sûr, rien ne permet de dire que les patchs à l’origine de ces 138 failles étaient des patchs hypocrites (c’est-à-dire délibérément conçus pour introduire ces failles, à l’insu des mainteneurs du noyau), et Qiushi Wu et Kangjie Lu ne le prétendent d’ailleurs pas. L’étude de ces patchs est intéressante en ce qu’elle offre une compréhension globale des mécanismes qui font qu’un mainteneur noyau peut « laisser passer » un patch causant une vulnérabilité — que la vulnérabilité soit introduite délibérément par un patch hypocrite ou soit le résultat d’une honnête erreur de la part de l’auteur du patch n’a en réalité pas beaucoup d’importance !



C’est pourquoi il conviendrait de parler de « patch problématique » plutôt que de « patch hypocrite » : un patch problématique est tout patch introduisant une faille potentielle, sans préjuger des intentions de son auteur.


En étudiant à la fois les patchs problématiques _acceptés_ et les patchs problématiques _bloqués_ (rejetés par les mainteneurs avant d’avoir atteint la branche principale du noyau) sur une période de six ans (de janvier 2015 à août 2020), Qiushi Wu et Kangjie Lu concluent que les mainteneurs du noyau détectent correctement les patchs problématiques un peu plus d’une fois sur deux (56,6 % de patchs problématiques bloqués).


C’est probablement l’aspect le plus navrant de toute cette affaire : le « papier des commits hypocrites » aurait pu être un papier réellement _intéressant_, si ses auteurs s’étaient contentés de cette étude rétrospective au lieu de vouloir faire dans le sensationnel en rapportant une expérience bidonnée… Le pire, c’est que maintenant qu’on sait que les auteurs ne sont pas dignes de confiance, on peut légitimement douter _aussi_ de leur étude rétrospective — ils ne fournissent aucune information sur les patchs qu’ils ont étudiés… — et donc du taux de 56,6 % qu’ils avancent.


Au-delà du papier, la revue massive de *tous* les patchs en provenance de l’Université du Minnesota, que le papier a indirectement déclenchée en avril 2021, apporte elle aussi quelques réponses sur la probabilité qu’un patch problématique passe au travers des mailles de la relecture par les mainteneurs. Des réponses fiables, étant donné [la transparence](https://lwn.net/ml/linux-kernel/202105051005.49BFABCE@keescook/) de la Linux Foundation.


Or donc, sur les 442 patchs revus, 78 introduisaient un problème quelconque. Les mainteneurs ont donc laissé passer environ 18 % de patchs problématiques.



Aucun de ces 78 patchs n’était « hypocrite », ce qui permet de souligner un point important et de comprendre le point de vue des développeurs noyau sur le « risque » posé par les patchs hypocrites : il n’est nul besoin d’imaginer un adversaire actif soumettant des patchs hypocrites pour voir arriver des bogues (et potentiellement des vulnérabilités) dans le noyau ! Les développeurs noyau doivent _déjà_ être sur leur garde pour tenter d’empêcher l’introduction _accidentelle_ de bogues ! (Ce qu’ils sont arrivés à faire, dans le cas des patchs en provenance de l’Université du Minnesota, dans 82 % des cas.) C’est exactement la _même_ vigilance qui est requise pour empêcher l’introduction _délibérée_ de bogues, ce n’est pas un risque distinct.



C’est ce que Greg Kroah-Hartman a tenté d’expliquer à Qiushi Wu lors [d’un échange en août 2020](https://lkml.org/lkml/2020/8/28/167), juste après la conclusion de l’expérience (à ce moment-là, ni Greg Kroah-Hartman ni aucun autre développeur n’est conscient de l’existence même de cette expérience ; Qiushi Wu est seulement un doctorant qui vient poser des questions sur la LKML) :



> > > > _(Qiushi Wu)_ N’importe qui peut soumettre un patch au noyau Linux.
>
> > > _(Greg Kroah-Hartman)_ En quoi serait-ce un « risque » ?
>
> > _(Qiushi Wu)_ Nous considérons la possibilité que des contributeurs soumettent des patchs malveillants et nous voulons réduire le risque que de tels patchs soient acceptés.
>
> _(Greg Kroah-Hartman)_ Vous ne voyez pas le problème sous le bon angle.
>
> TOUS les contributeurs font des erreurs, vous ne devriez traiter personne différemment. J’ai probablement commis moi-même plus de bogues que nombre de contributeurs, est-ce que ça fait de moi un « contributeur malveillant » ? Non, juste quelqu’un qui contribue beaucoup.
>
> Donc les patchs doivent être vérifiés attentivement quel que soit le contributeur, vous voyez ?
>
> Nous avons bien une notion de « confiance » parmi les développeurs noyau, c’est ce qui nous permet d’être efficaces. Sauf que l’idée n’est pas de faire confiance aux gens pour toujours écrire des patchs parfaits, mais plutôt de leur faire confiance pour être dans les parages pour réparer les dégâts quand un de leurs patchs se sera avéré incorrect — ce qui arrivera, nous sommes humains et tout le monde fait des erreurs.


# Les développeurs noyau ont-ils réagi de manière excessive ?


Avec le recul, la décision de Greg Kroah-Hartman, le 21 avril, de bannir _toutes_ les nouvelles contributions en provenance de l’Université du Minnesota, peut sembler excessive. Après tout, l’Université du Minnesota, c’est (tous départements confondus) environ [26 000 membres du personnel](https://idr.umn.edu/reports-by-topic-faculty-staff/faculty-and-staff-headcounts) et [66 000 étudiants](https://idr.umn.edu/reports-by-topic-enrollment/enrollments), quand l’affaire des commits hypocrites n’a impliqué que l’équipe de recherche de Kangjie Lu.



Avec le recul, oui.



Sauf qu’au 21 avril 2021, Greg Kroah-Hartman et les autres développeurs noyau ne connaissent absolument pas tous les détails donnés tout au long de cette dépêche. En particulier, ils ne savent pas qu’il n’y a jamais eu que cinq patchs hypocrites, puisqu’à ce moment-là, les chercheurs n’ont pas encore dévoilé l’étendue de leur expérience — ils ne le feront qu’une semaine plus tard, sous la pression de la communauté.



Par ailleurs, comme [le fait remarquer](https://lore.kernel.org/linux-nfs/YIBJXjCbJ1ntH1RF@mit.edu/) Theodore Ts’o :



> Le fait que le comité d’éthique de l’Université du Minnesota estime que les travaux du Professeur Lu ne constituent pas des recherches sur des sujets humains signifie qu’il n’y a aucune sorte de contrôle institutionnel sur ce genre de comportements au sein de cette université — donc bannir l’université entière pourrait bien être la seule réaction correcte, malheureusement.



En définitive, le rôle du bannissement était surtout d’envoyer un message à quiconque (à l’Université du Minnesota ou ailleurs) serait tenté de réaliser des expériences similaires à celle de Qiushi Wu et Kangjie Lu. Le message étant, selon les propres termes de Greg Kroah-Hartman, que « notre communauté n’apprécie guère d’être traitée comme un sujet d’expériences. »



Et le message a été reçu fort et clair, puisqu’en réponse l’Université du Minnesota a immédiatement (le jour même !) [« lâché » ses chercheurs](https://cse.umn.edu/cs/statement-cse-linux-kernel-research-april-21-2021) — alors que des membres de la communauté avaient pointé du doigt les problèmes éthiques de leurs travaux dès le mois de novembre 2020, sans que cela ne fasse réagir qui que ce soit au sein de l’université.


# Pour aller plus loin



- [Le “Menlo Report”](https://www.dhs.gov/sites/default/files/publications/CSD-MenloPrinciplesCORE-20120803_1.pdf), document de référence (aux États-Unis) posant les principes éthiques qui doivent régir les recherches en « technologies de l’information et de la communication ».
- [The Underhanded C contest](http://www.underhanded-c.org), un ancien concours de programmation C qui demande souvent d’écrire des logiciels munis de vulnérabilités dont on peut nier l’intentionnalité (ce qu’on peut rapprocher du concept de patch hypocrite tel que décrit dans le papier de Qiushi Wu et Kangjie Lu).
- [Les ressources pédagogiques du CNRS](https://comite-ethique.cnrs.fr/pedagogie/) en matière d’éthique et d’intégrité scientifique.

**N.D.M.** : à la suite de cette affaire Linux vient (mars 2022) de se doter de [guidelines à l’attention des chercheurs](https://github.com/torvalds/linux/commit/f09f6f9b69821c9efcf16e6b5b466ce9e263ca51) qui seraient tentés de se livrer à ce genre d’expériences.