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

Thibaut Keutchayan

03 mai 2021 à 16h11

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

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

Lire d'autres articles

Commentaires (25)

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.

Bombing_Basta

Compléments et précisons ici : L'université du Minnesota bannie du développement du noyau Linux - ZDNet

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

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.

raymondp

C’est en effet du grand foutage de gueule…

kyrios

Ce que vous appelez le collaboratif signifie open source (qui n’est pas forcément collaboratif) et il n’est pas plus vulnérable aux failles de sécurité que le propriétaire (qui peut aussi être collaboratif soit dit en passant - à moins que le code source de Windows ait été produit par un seul développeur). Windows a aussi son lot de failles et de backdoors. L’avantage du « collaboratif » est justement la validation que vous considérez comme un point faible : sur le propriétaire la phase de validation est souvent inexistante où repose uniquement sur des processus automatisé afin de réduire les coûts et on se contente des testes (de plus en plus automatisés) pour détecter les bogues → il est plus simple dans ces conditions d’introduire des failles de sécurité (volontairement ou pas) Des outils pour scanner le code et détecter des vulnérabilité sont utilisés dans les 2 cas sur les projets d’envergure mais ces outils ont des limites.

kyrios

Ça n’a rien à voir avec les linuxiens. Il y a de tels individus partout. Faut arrêter les amalgames.

Nmut

Vous avez raison de me faire remarquer que j’utilise collaboratif au lieu de Open Source collaboratif! Je ne parle pas de la validation qui est assez proche de celle d’un logiciel closed source, mais de la principale difficulté de l’Open Source: le contrôle des malveillances ou des erreurs. Car c’est ici que le travail de contrôle devient encore plus complexe, les contributeurs étant moins plus divers, moins surveillés et moins contrôlés par définition. Ceux qui ont déjà travaillé sur des TestU, de la validation ou de la vérification industrielles comprennent surement ce que je veux dire, même si je ne suis pas très clair… Quel contributeur n’a jamais eu un mal fou avec du code étrange, mal codé voir même buggé. Je me souviens du code BT et RS232 de Qt il y a quelques années ou on a du tout recoder parce qu’il ne respectait pas les règles de codage, qu’il était illisible et surtout qu’il était truffé de bugs: pas mal de jardinage évident (WTF!!!), beaucoup d’imprécisions, mauvais support des protocoles, …, la totale quoi.

raymondp

Tout à fait, cela s’appelle des « fans boys ». Des gens dépourvus de toute objectivité dès qu’on évoque leur marque préférée. Il suffit de lancer une discussion AMD vs Intel, iPhone/Androïd, Nvidia/AMD pour en trouver !

kyrios

Je ne sais pas… Quand je soumet un PR sur un projet open source, il y a TOUJOURS quelqu’un pour le revoir. Il y a presque toujours des templates à compléter et des standards sur la manière de structurer le code. Ce ne sont pas des PR qui viennent de nulle part sans qu’on sache pourquoi et le code doit être compréhensible pour qu’il soit validé et testé. On ne porte pas non plus la même attention à des nouveaux contributeurs qu’à des personnes qui ont déjà fait leurs preuves. Dans le cas de l’article, ces personnes ont clairement utilisé l’université pour gagner en crédibilité. Si ils avaient soumis le même code via un compte personnel sans lien avec l’université, il aurait peut-être été analysé avec plus d’attention. Quand je soumet du code dans un des repository de l’entreprise pour laquelle je bosse, le code est généralement automatiquement approuvé et quand c’est manuel, la personne qui approuve se contente généralement de vérifier que ça compile sans même jeter un œil au code. On part du principe qu’il y a un climat de confiance or bon nombre de sabotages viennent de l’intérieur. Et une entreprise vvictime de malveillance ne va pas s’en vanter. Tout ça pour dire qu’aucun système n’est parfait et des personnes malveillantes pourront toujours arriver à leurs fins, aussi bien dans l’open source que dans le code fermé auquel ils contribuent. Il ne faut pas être parano pour autant. L’avantage du code ouvert est qu’on peut facilement auditeur le code, vérifier si une vulnérabilité est effectivement corrigée et le cas échéant faire soi-même un patch. Avec du code propriétaire, on doit croire l’éditeur (si il s’agit d’un cas compliqué à tester), et on dépend de son bon vouloir pour avoir un correctif (patch payant, version plus supportée, etc.). Bref, ce genre d’incident n’entame pas ma confiance dans l’open source. Au moins ça à le mérite de forcer à davantage de vigilance… Au moins pour un temps.

Nmut

J’ai aussi toujours confiance en l’Open Source, mais c’est quand même un point délicat. Si ta boite ne fait pas plus de tests, je suppose que ce n’est pas du code « sensible »! Dans le cas de l’aéronautique ou je bosse actuellement, ou de l’automobile ou j’ai bossé, il y a plusieurs niveau de certification et de vérification, avec des boites différentes pour réduire au maximum les risques d’oubli, de mauvaises habitude voir de malveillance. Et c’est souvent d’ailleurs dans ces vérifications que l’on tombe sur les problèmes de l’Open Source ou de Closed Source, en plus des problèmes internes!

Blackalf

@metta messages supprimés pour le motif message non-constructif/hors-sujet. Et il est toujours conseillé aux nouveaux inscrits d’aller lire la charte du forum. Charte de la communauté Clubic Débat sur l'actu Charte de la communauté Clubic Cette charte propose quelques règles de conduite qui favoriseront des échanges respectueux et constructifs entre membres de la communauté. Merci à tous et à toutes de faire votre maximum pour respecter ces consignes. N’hésitez pas à solliciter l’aide des modérateurs si vous estimez que des discussions dépassent les limites fixées par cette charte. 1. Participez aux discussions Nous encourageons chacun à exprimer ses idées sur les sujets qui l’intéressent, et à f…

bmustang

entièrement d’accord avec la décision de bannir cette université jusqu’à nouvelle ordre, on ne peut pas resté les bras croisés, inactif face à de telle risque aussi grave.

benben99

Il y a des individus ou des organisations qui ont des intérêts à inclure des failles dans des logiciels open sources. Cela pourrait très bien être une agence gouvernementale des USA derrière cela… On va vu avec Snowden, ils ne se gênent pas pour espionner, mais déchirent leurs chemises quand un autre pays espionne. Bref, même si c’est open-source, il faut se méfier des contributeurs… d’où l’importance des « code reviews ». C’est une sage décision d’avoir bani cette université. Il y a quelque chose de louche dans cette affaire.

newseven

J’ai l’impression que l’étudiant a découvre quel que chose qui ne le devrais pas être . Malheureusement dans l’informatique ou même dans la nature c’est dans la Méthode essai-erreur que l’on évolue ! Sans les erreurs les choses n’avancent pas très vite . La ce n’est pas un code Linux qui est dans la nature . Aucun Linux utilise présentement se code dans leur noyaux . Je suis sur qui a découvert une faille potentiel dans le système " peut-être x 86 " que tout monde veut enterrer sous peur de poursuite . " Dans ce cas-là " il n’aura pas juste les Linux de concerner . Comme dit benben99 Il y a quelque chose de louche dans cette affaire. Il ne nous dit pas tout la vérité .

tfpsly

newseven: J’ai l’impression que l’étudiant a découvre quel que chose qui ne le devrais pas être . … La ce n’est pas un code Linux qui est dans la nature . … Je suis sur qui a découvert une faille potentiel dans le système " peut-être x 86 " que tout monde veut enterrer sous peur de poursuite . N’iimporte quoi… Les changelistes de ces étudiants sont dispos C’est la base de code principale de Linux Il n’y a pas de vraie correction de bug, mais au contraire un ajout volontaire de bugs dans ces changeslistes Le premier papier de ces étudiants où ils expliquent ce qu’ils ont fait l’année précédente dans leurs premières changeliste est disponible. Non seulement il n’y a rien de caché, mais en plus les étudiants ont expliqué ce qu’il faisaient. Y voir du complotisme, c’est vraiment vouloir s’aveugler soi-même.

jvachez

Et oui le côté libre de Linux est une illusion. Linux est dirigé par des personnes comme une entreprise. Il y a des gens qui décident qui peut fournir du code et qui ne peut pas, quelle fonctionnalité on ajoute ou quelle fonctionnalité on refuse. C’est un open source très closed source finalement car l’ouverture est très limitée, c’est au bon vouloir des gens là. La principale différence avec une vraie entreprise c’est que les gens bossent gratuitement grâce à ce système.

Kriz4liD

Franchement , faut vraiment etre aveugle pour raconter de la ****e comme tu le fais. Des milliers de personnes et d’entreprises travailles sur le noyau, derrière chaque patch il y a des grandes firmes (Microsoft, AMD , Intel , NV…) , des universités , des petits devs , et dans tout ça , il y a un gros lot de Bugs et de failles potentiel dont une vérification est plus que nécessaire. Quand des étudiants , surement supervisés par leurs profs , essaye de soumettre volenterement du code bugué , tu le prends comment ? tu l’integres car " ohhh c’est open source tout le monde peut contribué " ??? mais t’es vraiment à l’ouest mon gars. Travailler gratuitement … lol .

phri

Ça part certainement d’une bonne intention, mais ils oublient que Linux n’est pas un jouet expérimental pour geeks, mais le noyau utilisé en prod d’une chiée de serveurs, de machines, avec un haut degré de sécurité. Si tout le monde commence à faire ce genre d’expérience, ça créera un tel risque pour la sécurité que les entreprises qui ont besoin de sécurité vont tout simplement se passer de Linux. tester la sécurité, mettre à l’épreuve, oui, mais pas n’importe comment.

MattS32

jvachez: Il y a des gens qui décident qui peut fournir du code et qui ne peut pas, quelle fonctionnalité on ajoute ou quelle fonctionnalité on refuse. Ben oui, il faut bien qu’il y ait un minimum de gouvernance pour pas que ça devienne n’importe quoi. Mais il y a dans quasiment tous les gros projets open-source un processus démocratique pour attribuer les pouvoirs, c’est pas un gars tout seul ou un groupe fermé qui décident de tout. Et surtout, comme ça reste de l’open-source, ça n’empêche pas à quiconque d’implémenter une fonctionnalité dont la communauté ne veut pas : il suffit de forker. jvachez: La principale différence avec une vraie entreprise c’est que les gens bossent gratuitement grâce à ce système. L’écrasante majorité des contributions à l’open-source sont faites par des gens qui ont été payés pour. Le geek qui fait ça chez lui dans son coin juste pour le plaisir, c’est un mythe auquel ne croient que ceux qui n’ont jamais vraiment travaillé dans l’open-source…

tfpsly

MattS32: L’écrasante majorité des contributions à l’open-source sont faites par des gens qui ont été payés pour. Les contributeurs indépendants sont loin d’être une petite minoritaire : 753×882 29.1 KB

MattS32

D’abord, c’est pas parce que le commit est fait avec une adresse perso que le travail n’a pas été fait en étant payé par une boîte. J’ai déjà poussé plus d’une fois mes contributions avec une adresse perso, bien qu’elles aient été réalisées pendant mon temps de travail, parce que mon employeur ne souhaitait pas l’exposer officiellement (contribution sur des librairies PHP et Boostrap qu’on utilisait sur un projets internes, y avait des bugs chiants, on les a corrigés, et on a poussé les correctifs avec l’accord de notre hiérarchie, parce qu’on leur a bien fait comprendre que c’était la bonne façon de faire et que ça nous ferait même faire des économies à moyen terme puisqu’on n’aurait pas à repatcher à chaque mise à jour de la lib). Certains parmi les plus gros contributeurs ont aussi l’habitude de contribuer avec une adresse perso, pour qu’ils puissent changer d’employeur tout en gardant le même identifiant auprès de la communauté. C’est toutefois de nos jours souvent remplacé par une adresse sur le domaine du projet. Tiens, prenons un exemple au « hasard ». Dans les derniers commits sur torvalds/linux.git, le plus récent à avoir utilisé une adresse non pro, c’est Helge Deller, qui utilise une adresse gmx.de. Et si on regarde son profil, on voit qu’il est responsable du LinuxLab de SAP. Donc en faite de fortes chances que son activité sur le noyau Linux soit bel et bien rémunérée, même s’il pousse avec une adresse perso (et on peut pousser un poil plus loin en constatant qu’une large majorité de ses commit sont faits en semaine à des horaires de bureau). Le premier @gmail.com que j’ai trouvé, c’est Andrey Konovalov, employé de Google, qui travaille sur la recherche et la corrections de failles dans les noyaux Linux et Android… Là encore, y a donc de fortes chances que le gros de son activité sur le repo git de Linux soit directement liée à son boulot. Ensuite, même si on considérait que tous ces gmail.com sont des indépendants, c’est certes le domaine qui a fait le plus de commits, mais ça ne représente tout de même que 9% du total des commits (donc une petite minorité face à une majorité qui a commité avec des domaines d’entreprise… Gmail étant quasiment le seul provider de mail public listé dans ce top 30, il y a aussi gmx, mais loin derrière…). Enfin, le nombre de commits est de toute façon une métrique qui atteint vite ses limites… Un indépendant qui va faire 10 commits modifiant chaque fois une ligne, donc des modifications absolument mineures, si ce n’est cosmétique (genre correction de typo dans un fichier de langue…), ça compte comme 10 fois plus qu’un professionnel qui pousse en un seul commit le travail d’une semaine pour ajouter une feature majeure à un produit… Histoire de se faire une idée, sur un des projets sur lequel j’ai bossé, le 2ème plus gros contributeur a fait 117 commits, mais seulement 8275 lignes de code. Y’en a un autre qui a fait 70 305 lignes, mais en seulement 26 commits… Y a des chances qu’en pratique il ait contribué bien plus que le précédent…

newseven

Tu penses que étudiants voulait juste créé un bug dans le noyau de Linux volontaire . J’imagine très bien la scène . Professeur " universitaire " ; pouvons nous amusez a créé des bugs dans Linux pour le faire planter " question de s’amuser un peu . Voyons donc ça pas d’allure comme histoire . C’est sur que on ne connait pas tout l’histoire mais il avait surement un but à cette manœuvre et ce n’était surement pas pour mal faire . Là c’est de la chasse au sorcière . Trouver un coupable pour une histoire non aboutie et qui a été abandonné . Il n’y a pas de bobo c’est quoi le but de la manœuvre du bannissement .

tfpsly

newseven: Tu penses que étudiants voulait juste créé un bug dans le noyau de Linux volontaire . J’imagine très bien la scène . Professeur " universitaire " ; pouvons nous amusez a créé des bugs dans Linux pour le faire planter " question de s’amuser un peu . Voyons donc ça pas d’allure comme histoire . Ah, donc tu n’as même pas lu l’article. Bon, bah pas la peine de discuter plus.

newseven

J’ai lu l’article et je vois pas le problème . En résumé : Une étudiants a induite des codes dans le noyau de Linux surement pour améliorer sans tenir compte de l’aspect de la sécurité ? Par-contre L’Université du Minnesota dit que c’est un logiciel qui a créé le bug et bla bla bla a qui la faute ! pis alors Si je manque mon gâteau est ce que je n’aurait plus le droit de faire du gâteau . Je l’ai écrie que l’évolution fonction dans la Méthode essai-erreur ! C’est la base même de tout composant l’électronique .

tfpsly

newseven: J’ai lu l’article et je vois pas le problème . … Une étudiants a induite des codes dans le noyau de Linux surement pour améliorer sans tenir compte de l’aspect de la sécurité ? Faux

newseven

newseven: Une étudiants Petit question est ce que le code a été supprimé du noyau ou pas parce que ce n’est pas claire . Pour l’heure, le réexamen des travaux de l’université par Linux prévoit néanmoins de conserver les correctifs valides. Aussi il ne stipule pas quand le code a été créé et été introduit dans le noyau du Linux . La seule chose qui est surtout démontré c’est la découverte du problème qui a été découvert durant le 22 avril 2021 .

Voir tous les messages sur le forum

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

Les codes de la discorde

Une surréaction du board de Linux ?

A découvrir en vidéo

Commentaires (25)

Top app & logiciels

Sur le même sujet