On dit Linux sécurisé, mais nous n’avons pas accès à 100 % du code source du noyau linux.

En effet il y a des « blob » [ Blob : binary large object. C’est un objet binaire souvent utilisés pour stocker des données volumineuses telles que des images, des vidéos ou des fichiers audio dans le champ d’une table d’une base de données] qui sont chargés sous la forme de firmwares, et dont personne ne connaît réellement le contenu ; et on ne parle pas du bios ou de la partie UEFI !

Voici un échange autour de la question suivante : « la NSA a-t-elle une porte dérobée (backdoor) dans Linux ? » . La réponse est « très probablement oui » :

1 - D’un côté, Linus Torvalds lui-même a admis que le gouvernement américain lui avait demandé d’ajouter une porte dérobée. Le résultat de cette demande n’a pas été diffusé …

2 - D’autre part, il existe des mécanismes pour intégrer du code malveillant dans de l’open source même si quelqu’un vérifie le code, comme l’a prouvé Ken Thomson en 1984 en changeant simplement de compilateur (http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf – cf la traduction de ce texte à la fin de cet article).

3 - Enfin, beaucoup de portes dérobées peuvent se présenter sous la forme de bugs très subtils dans le logiciel, qui dépendent du timing et de conditions « étranges » qui les rendent presque impossibles à déceler. Depuis que la NSA a introduit elle-même des logiciels dans le noyau (SELinux), elle a largement eu les moyens de le faire.

Pour être honnête, peu importe à ce stade, car ce n’est qu’un vecteur d’attaque parmi d’autres, étant donné qu’il peut même y avoir des rootkits [« Un rootkit est un ensemble de techniques mises en œuvre par un ou plusieurs logiciels, dont le but est d’obtenir et de pérenniser un accès à un ordinateur le plus furtivement possible, à la différence d’autres logiciels malveillants… (wikipedia)] de firmware dans les disques durs ; on peut raisonnablement supposer que tout système d’exploitation est compromis par défaut. La sécurité n’existe pas à 100% car ce n’est qu’une question de temps et de moyen. Beaucoup de bugs ou de failles sont laissés pour pouvoir être exploités et je ne parle pas des failles « zéro day » ! [ « Une faille (ou vulnérabilité zero-day) est une vulnérabilité informatique n’ayant fait l’objet d’aucune publication ou n’ayant aucun correctif connu. L’existence d’une telle faille sur un produit informatique implique qu’aucune protection n’existe, qu’elle soit palliative ou définitive … (Wikipedia). ] De plus quand on voit le potentiel des ordinateurs quantiques à casser les algorithme à base de factorisation de nombres premiers beaucoup utilisés dans le chiffrement on peut se poser des questions...

Traduction de l’article de Ken Thomson :

Introduction
Je vais décrire comment insérer un cheval de Troie dans le compilateur C.
Ce cheval de Troie sera capable de se propager lui-même, et sera pratiquement indétectable. Je vais ensuite montrer comment cette technique peut être utilisée pour compromettre un système, même lorsque le code source est disponible et inspecté.
Le problème est de savoir en qui ou en quoi faire confiance. Il est tentant de faire confiance aux personnes qui ont écrit les logiciels. Je suis moi-même programmeur, et j’ai confiance en mon code. Mais devrais-je ?

Partie 1 : Programmes auto-reproducteurs
Le problème de l’écriture d’un programme qui peut produire sa propre description est un classique de l’informatique. Ce type de programme est appelé un programme “auto-reproducteur”. L’idée est la suivante : écrire un programme qui, lorsqu’il est exécuté, produit exactement son propre code source en sortie. Une manière simple de faire cela est d’avoir une partie du programme qui contient une représentation des données, et une autre partie qui imprime ces données. Cependant, il existe une technique plus élégante qui permet au programme de se reproduire sans contenir explicitement une copie complète de lui-même. Ce genre d’exercice est intéressant parce qu’il montre qu’un programme peut manipuler des représentations de lui-même.

Partie 2 : Enseigner quelque chose au compilateur
Supposons que nous voulions ajouter une nouvelle fonctionnalité au langage C. Par exemple, supposons que nous voulions que la séquence \n soit reconnue comme un saut de ligne. Nous devons modifier le compilateur pour reconnaître cette séquence et la traduire correctement. Une fois que le compilateur a été modifié, il peut être utilisé pour se compiler lui-même. Cela signifie que le compilateur peut “apprendre” cette nouvelle fonctionnalité. Après cela, le code source du compilateur peut être modifié pour inclure directement cette fonctionnalité, et le compilateur peut se recompiler lui-même. Finalement, la modification initiale peut être retirée, car le compilateur a déjà intégré ce comportement.

Partie 3 : L’attaque (porte dérobée)
Considérons maintenant un programme de connexion (login). Supposons que nous modifions le compilateur de telle sorte que, lorsqu’il compile ce programme de login, il insère automatiquement une porte dérobée. Cette porte dérobée permettrait à un utilisateur particulier de se connecter sans fournir le mot de passe correct. Ainsi, même si le programme de login semble correct dans son code source, la version compilée contiendra une faille. Quelqu’un qui inspecte le code source du programme de login ne verra rien d’anormal. La porte dérobée n’apparaît que dans le programme compilé.

Partie 4 : Auto-propagation du compilateur compromis
L’étape suivante consiste à modifier le compilateur pour qu’il reconnaisse quand il compile une nouvelle version de lui-même. Dans ce cas, il insère non seulement la porte dérobée pour le programme de login, mais aussi le code qui permet cette insertion. Ainsi, même si le code source du compilateur ne contient aucune trace de cette modification, le compilateur compilé continuera à insérer la porte dérobée. Si quelqu’un examine le code source du compilateur, il ne verra rien de suspect. Pourtant, le compilateur binaire reste compromis. Cette méthode permet de créer une attaque qui survit même après une réécriture complète du code source.

Conclusion
La morale de cette histoire est que vous ne pouvez pas faire confiance à du code que vous n’avez pas entièrement créé vous-même. Et même dans ce cas, vous devez aussi faire confiance aux outils utilisés pour le créer. Aucune quantité de vérification au niveau du code source ne permettra de détecter ce type d’attaque.Vous devez faire confiance à la chaîne complète de développement, du matériel jusqu’aux logiciels les plus élevés.