C’est une effet domino inédit et qui pose certaines questions. Des chercheurs de l’université du Minnesota publient une étude intitulée : on the feasability of stealthily introducing vulnerabilities in open source software via hypocrite commits. Pourquoi donc Greg Kroah-Hartman, le mainteneur des branches stables du noyau, a pris cette décision radicale ? 

Le postulat de départ de l’étude est d’étudier l’insécurité dans le monde open source et comment des développeurs pourraient introduire volontairement une faille dans le code stable d’un projet open source, ici, le noyau Linux. Et les étudiants montrent si c’est possible de le faire en respectant la gouvernance. 

Les étudiants ont donc volontairement développés des commits vulnérables. En fait, ils montrent les avantages et les limites du modèle open source : par définition il est ouvert, les projets sont souvent maintenus par des volontaires et les ressources sont limitées, un logiciel open source est complexe, voire, très complexe. Le noyau Linux est un des plus complexes avec 22 000 contributeurs. Pour placer un commit corrompu, les étudiants ont développé des outils pour détecter les branches de codes les plus intéressantes. Les vulnérabilités dans le noyau sont nombreuses et elles sont comblés au fur et à mesure selon la criticité. 

Cependant, les étudiants n’ont pas fait de force brute, il fallait agir en suivant les procédures tout en identifier les points faibles. Cela montre aussi que des hackers méthodiques peuvent introduire du code vérolé en respectant les règles, à condition que la revue de code ne voit pas le potentiel problème de sécurité. Les codes soumis noyaient intelligemment les vulnérabilités en multipliant les conditions et les localisations dans le code. Bien entendu, cette méthode nécessite une maîtrise des procédures, du code review, etc. Résultat : oui il est possible de soumettre des commits avec des codes vérolés même s’il faut une grande rigueur. 

Cette étude n’a pas plu à Greg qui argue que les développeurs du kernel n’aiment pas être testés. Résultat : le 21 avril, Greg a envoyé à l’université du Minnesota une lettre contre cette méthode : « 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. »

Résultat : Greg bannit tout contributeur avec une adresse mail de l’université !

De son côté, l’université a suspendu les deux chercheurs pour enquêter sur leurs méthodes. Le 24 avril, les chercheurs présentaient leurs excuses… Effet domino quand tu nous tiens.

Le mainteneur en chef a-t-il eu raison de réagir ainsi et de faire retirer le plus vite possible l’ensemble des commits des chercheurs ? Cette position a été critiquée par d’autres membres de la communauté. 

Que Greg ne soit pas content, c’est logique car cela met aussi en cause son propre travail de mainteneur. Que l’on réprouve, ou non, la méthode du hypocrite commit, les chercheurs mettent en évidence des failles dans la sécurité et les procédures et cela démontre la faisabilité d’introduire de tels codes. Cependant, ce n’est pas à la portée de tout hacker.