L'Université du Minnesota est interdite de contribuer au noyau Linux... Que s'est-il donc passé ?

Thibaut Keutchayan
Publié le 03 mai 2021 à 16h11
© shutterstock
© shutterstock

Depuis le 22 avril 2021, une polémique grandit aux Etats-Unis après que les membres de l'Université du Minnesota ont été interdit de contribuer aux recherches sur le noyau Linux.

Un élève de l'établissement a proposé des codes contenant de potentielles failles de sécurité, provoquant un bannissement systématique de toute donnée provenant d'une adresse e-mail de l'Université du Minnesota, par Linux. Une décision critiquée par plusieurs membres de la communauté Linux, jugeant la sentence excessive.

Les codes de la discorde

La tension n'est pas encore retombée dans l'Etat du Minnesota. Le bannissement de tout travaux en lien avec Linux, des membres de l'Université ne cesse d'alimenter la controverse. D'un côté, selon les responsables de Linux, l'Université du Minnesota serait coupable d'avoir sciemment soumis des codes contenant d'importantes failles de sécurité. De l'autre, les chercheurs affirment avoir seulement mené à bien des recherches dans la continuité d'un premier article publié début 2021.

Leurs travaux universitaires avaient alors été menés pour pointer du doigt les failles de sécurité existantes, montrant qu'un code malveillant pouvait outrepasser tout processus d'approbation et potentiellement infecter le noyau Linux. Or, après ces codes infectés, un étudiant de l'université a posté un code, a posteriori inoffensif, mais demandant de nouvelles révisions, ce qui a conduit Greg Kroah-Hartman, responsable du noyau et membre de la Fondation Linux, à demander à rejeter le moindre code qui émanerait d'une adresse e-mail umn.edu.

Une surréaction du board de Linux ?

Cette décision forte prévoit également le réexamen de l'ensemble des codes soumis par l'Université du Minnesota. Un travail colossal justifié, selon Kroah-Hartman, par la volonté pour les développeurs de Linux de ne pas servir de « cobaye » en subissant de potentielles nouvelles failles de sécurité induites par des codes des membres de l'université.

Une tentative de clarification de la part de plusieurs chercheurs n'y aura rien changé : leurs travaux pour déceler les failles dans le processus de soumission des codes de Linux sont suspendus jusqu'à nouvel ordre.

Deux incertitudes demeurent à ce stade. La première concerne l'origine du code défectueux décrié par Kroah-Hartman. Ce dernier réfute l'argument de l'Université du Minnesota selon lequel le code aurait été créé par un outil et non par un humain. La seconde est liée à l'origine même du code soumis, qui pourrait potentiellement ne pas faire partie du projet de recherche. Son envoi par le biais d'une adresse e-mail umn.edu et sa correction via des adresses Gmail générées aléatoirement ont achevé de semer le doute au sein du board de Linux.

Alors que le noyau fête ses trente ans en 2021, cette année restera à priori marquée par cette décision controversée et critiquée par plusieurs membres de la communauté Linux, notamment du fait de la réintroduction potentielle de bugs corrigés au préalable par le travail de l'Université du Minnesota. Pour l'heure, le réexamen des travaux de l'université par Linux prévoit néanmoins de conserver les correctifs valides.

Sources : The Verge, Zdnet

Thibaut Keutchayan
Par Thibaut Keutchayan

Je m'intéresse notamment aux problématiques liant nouvelles technologies et politique tout en m'ouvrant à l'immense diversité des sujets que propose le monde de la tech' quand je ne suis pas en train de taper dans un ballon.

Vous êtes un utilisateur de Google Actualités ou de WhatsApp ?
Suivez-nous pour ne rien rater de l'actu tech !
Commentaires (0)
Rejoignez la communauté Clubic
Rejoignez la communauté des passionnés de nouvelles technologies. Venez partager votre passion et débattre de l’actualité avec nos membres qui s’entraident et partagent leur expertise quotidiennement.
Commentaires (10)
Nmut

On touche du doigt les limites du collaboratif.
La validation du code est le point faible. Une « petite » protection de ce point faible, c’est bien sûr le retrait de ce que l’on a détecté comme problématique mais aussi le bannissement de l’origine… Le but de la « recherche » était intéressant pour détecter les failles de la validation, mais c’était jouer avec le feu.
Quel est votre avis sur cette question essentielle de la sécurité de l’Open Source?

sirifa

Les « chercheurs » payent le fait qu’ils aient voulu tester les contributeurs en leur donnant plus de travail.
Soumettre des failles pour analyse (sans que les contributeurs le sachent) pour voir si c’est cette modification passe (et si c’est accepté alors rattraper la modification avant qu’elle soit vraiment intégré).

Je peux comprendre le bénévoles à qui ça donne plus de travail pour les bénévoles qui n’ont déjà pas assez de temps disponible pour les choses valables.
Si c’est pour donner du taff en plus pour finalement une recherche qui ne semble pas soutenu par l’université des « chercheurs », c’est quand même con !
Donc le bannissement c’est aussi pour faire réagir l’université et stopper les recherches qui dégradent le travail des bénévoles sans apporter de bienfait sur le long terme.

Aristote76

Y a des Limites à ennuyer les gens juste pour voir le résultat, bien fait pour cette université et peut être qu’avec de telles sanctions on limiterai les tentatives de hack crées, rien que pour le fun. Ce bannissement devrai être défendu et généralisé dans nombre de cas, on pourrai espérer laver un peu le web.

Bombing_Basta

Leurs travaux universitaires avaient alors été menés pour pointer du doigt les failles de sécurité existantes, montrant qu’un code malveillant pouvait outrepasser tout processus d’approbation et potentiellement infecter le noyau Linux.

Faut croire que leur petit jeu n’est pas passé entre les mailles du coup ^^

Malheureusement, cela risque de donner des idées à d’autres…

tfpsly

Le pire étant que dans leur papier ils disent sur les 5 patchs « trompeurs » envoyés, deux ont réussi à tromper les mainteneurs parce que ces patchs n’ont pas été refusé pour les bugs que les chercheurs essayaient d’insérer… Mais pour d’autres bugs que les chercheurs n’avaient pas vu. Tu parles d’un « succès »

Clairement la communauté Linux a autre chose à foutre qu’être un cobaye involontaire et non rémunéré pour une recherche d’un candidat PhD…
Et si les changelistes les plus récentes ont été générées automatiquement par un outil de détection de bugs (comme essayent de l’affirmer ces chercheurs), la communauté n’a jamais demandé à être le sujet d’un alpha ou béta test de leur outil foireux.

La réponse finale de Kroah-Hartman le résume bien :

You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them and published a paper based on that work.

Now you submit a new series of obviously incorrect patches again, so what am I supposed to think of such a thing?

They obviously were NOT created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches?

When submitting patches created by a tool, everyone who does so submits them with wording like « found by tool XXX, we are not sure if this is correct or not, please advise. » which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect.

A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid « fix » is totally negligent on your part, not ours. You are the one at fault, it is not our job to be the test subjects of a tool you create.

Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way.

Our community does not appreciate being experimented on, and being « tested » by submitting known patches that are either do nothing on purpose or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.

raymondp

Le modèle collaboratif de linux est un modèle qui marche et qui a fait ses preuves. Lors de chaque nouvelle release, des stats sont produites et les chiffres sont impressionnants, de mémoire : 90 « gros » contributeurs par release, 1000 contributeurs significatifs et 10000 mineurs.
Mais dans ce qui est décrit, à savoir entre les travaux de recherche et ce qui a été posté, on a l’impression que le doute des mainteneurs du noyau est que développeur a voulu créer un « exploit », en gros démontrer par la pratique le thème de sa recherche : montrer qu’il pouvait contourner le processus d’approbation. Le problème c’est que cela a eu l’effet inverse. Le besoin de nouvelles révisions a été décelé par le processus d’approbation. La question est donc de savoir si d’autres soumissions de code n’ont pas passé les mailles du filet.
D’où la suspicion, en tout cas c’est ce que je comprends, mais à vrai dire je ne connais pas le processus d’approbation.

Edit : ok, j’avais pas lu les autres posts, à priori c’est plus de l’incompétence de l’UMN alors

tfpsly

Ton lien est le 2nd lien source de l’article, juste au dessus :wink:

Bidouille

Ah les linuxiens, ils ne changeront jamais. Je me souviens d’avoir été injurié, il y a quelques années, après avoir posté un message sur un forum en disant que j’avais des soucis avec ma carte graphique sous Linux, alors que celle-ci fonctionnait parfaitement sous Windows. Pour beaucoup, Linux est comme une religion alors si l’on ne croit en aucun dieu, c’est foutu.

Bombing_Basta

lol en effet, je regarde rarement les sources, my bad…
Par contre y’a eu coupe drastique sur les explications fournies dans cette source du coup.