[La réflexion qui suit est sans doute assez décousue et mal écrite, parce que j'écris comme les idées me viennent, sans prendre le temps de les structurer correctement, et je n'ai pas envie de me relire. C'est même tellement en vrac que les paragraphes qui suivent peuvent sans doute se lire dans à peu près n'importe quel ordre.]
Hier a été révélé un trou de sécurité assez grave dans le noyau Linux (détails ici, ici et là ; et là pour une explication très détaillée). Et ce n'est pas comme si c'était rare : des vulnérabilités de cette nature sont annoncées environ tous les deux ou trois mois (estimation au doigt mouillé, je n'ai pas fait de stats précises). À chaque fois je perds des heures à recompiler, ou au moins réinstaller, des noyaux pour toute une flopée de machines que j'administre (déjà pour mes DreamPlugs c'est douloureux, et pour mon téléphone j'ai jeté l'éponge).
C'est tout de même ennuyeux : ça veut dire, par exemple, que toute
personne ayant un téléphone Android et n'ayant pas reçu une mise à
jour depuis hier, est à la merci d'une application malicieuse qu'il
installerait ou aurait déjà installée. (Bon, le côté positif, c'est
que ceux qui ont un téléphone Android verrouillé peuvent en profiter
pour le déverrouiller, i.e., devenir root dessus.)
Pour éclaircir les choses pour le lecteur profane, précisons que la plupart des systèmes informatiques actuels distinguent essentiellement trois niveaux de confiance :
- les administrateurs (
rooten jargon Unix), qui ont un accès complet à la machine, - tout ce qui tourne sur le système mais qui n'est pas administrateur (les utilisateurs non-privilégiés), et qui a donc un accès limité à certaines ressources,
- et tout ce qui n'est pas censé avoir accès au système (i.e., le reste du monde).
Il y a donc, en simplifiant, deux barrières à maintenir : la
première interdit aux utilisateurs non-privilégiés d'acquérir le
privilège d'administrateur, et quand il y a un trou dans cette
barrière le jargon Unix parle
de local root exploit ; la
seconde interdit au monde extérieur d'entrer dans le système ; parfois
un trou permet de passer à travers les deux barrières simultanément,
et on parle de remote root
exploit (heureusement, c'est très rare). C'est évidemment très
simplifié, parce qu'il y aussi des barrières entre les
différents utilisateurs non-privilégiés. Le trou que je prends comme
exemple est un local root exploit,
i.e., un trou dans la première barrière : toute personne ayant un
accès à un système Linux peut en prendre un contrôle complet. Par
exemple, une application sur un téléphone Android opère comme un
utilisateur non-privilégié (il y en a un par application,
essentiellement), et comme Android utilise le noyau Linux et que cette
vulnérabilité concerne toutes les versions depuis fort longtemps,
toutes les architectures, et quasiment toutes les circonstances, ces
applications peuvent passer administrateur. Bon, heureusement, on
espère que l'immense majorité des applications ne sont pas malicieuses
(et notamment celles qu'on utilise depuis longtemps n'ont certainement
pas été écrites pour déclencher du code malveillant le jour où un trou
de sécurité serait découvert), néanmoins il est certain qu'il y en a.
Par ailleurs, cela signifie que si une application, sur un système
Linux quelconque, à défaut d'être malveillante, est elle-même
vulnérable à autre chose (i.e., qu'il y a un trou dans la deuxième
barrière, ce qui est possible pour à peu près n'importe quoi qui
communique avec l'extérieur, soit beaucoup de choses), toute
la sécurité est perdue.
Je prends surtout l'exemple des téléphones Android, parce que pour beaucoup d'autres systèmes Linux, notamment tout système sur lequel il n'y a qu'un seul compte utilisateur, la barrière entre utilisateur et administrateur ne sert pas à grand-chose : dès que le navigateur web est vulnérable, de toute façon le plus grave est déjà acquis.
Certes, le fait qu'il y ait un trou n'est pas la fin du monde : une vulnérabilité, ça se corrige, le correctif est déjà paru, il suffit de l'appliquer (en plus, pour ce trou particulier, il est possible sur certains systèmes d'appliquer un correctif « à chaud », une rustine sur le trou, comme montré par le deuxième lien tout en tête de cette entrée).
Sauf que : les fabricants de téléphone ne sont généralement pas très pressés d'appliquer des correctifs de sécurité. Ils ne le font que lentement, et, bien sûr, que pour leur tout derniers modèles : HTC, Motorola et toute la bande n'ont qu'un intérêt très faible à s'occuper de la sécurité de leurs clients d'il y a deux ou trois ans. Je pense que les pouvoirs publics devraient imposer à toute personne qui vend un téléphone mobile (ou équivalent : tablette ou autre) qui ne soit pas complètement ouvert de fournir des mises à jour de sécurité pour tous les problèmes portés à sa connaissance et pour une durée clairement annoncée lors de l'achat de l'appareil, et qui ne pourrait pas être inférieure à cinq ans. Ou alors ils doivent fournir toutes les informations nécessaires pour que l'homme de l'art (la communauté, donc) puisse corriger lui-même les trous de sécurité. Parce que actuellement, recompiler un noyau Linux pour son téléphone (sans même parler du reste d'Android), c'est extrêmement difficile : les sources de Linux sont peut-être disponibles, mais pas la configuration exacte que le fabricant a utilisée, sans parler des patchs propriétaires et drivers binaires.
Le problème des trous de sécurité, aussi, c'est que ceux qui les exploitent sont malins : le plus souvent, ils ne l'utilisent pas directement contre le système dont ils exploitent un trou. Par exemple, quand j'attire l'attention de ma maman sur l'importance de mettre à jour tous les logiciels sur son Mac (notamment le lecteur Flash, dont on découvre un trou de sécurité, lui, quasiment toutes les semaines), elle me dit qu'elle n'a rien de vraiment important dessus : ce qui est sans doute vrai, mais ce qui intéresse les black hats payés par la mafia russe ou chinoise ce n'est pas d'avoir accès aux photos de chat sur le Mac de ma maman, c'est de se servir de ce Mac comme un relai ou membre d'un botnet pour, dans le meilleur des cas, envoyer du spam pour du Viagra, et dans le pire des cas, monter des attaques denial-of-service (c'est-à-dire qu'on ne cherche pas à pénétrer la cible, on cherche à la submerger de requêtes) contre, par exemple, l'architecture centrale d'Internet.
Tout ceci est fort déprimant parce que la sécurité informatique est un sujet sur lequel l'utilisateur lambda n'est pas renseigné, et on ne peut donc pas s'attendre à ce qu'il ait des réactions sensées — le plus souvent, cela reste au niveau du quasi-rituel, comme faire tourner des antivirus. Et surtout, il faut bien l'avouer : nous (nous humains, collectivement) ne savons pas programmer : en théorie il est parfaitement possible de faire du code qui ne comporte aucun trou de sécurité, mais nous ne savons pas (il y a des gens qui prétendent savoir écrire du code sans aucun trou de sécurité, et qui ont sans doute raison, mais bizarrement ils n'écrivent jamais quelque chose d'aussi complexe qu'un navigateur web). Du coup, on se retrouve devant cette boucle infinie : trouver un trou, se précipiter pour le boucher, attendre le suivant, répéter à l'infini. Et celui qui a trouvé un trou sans prévenir les autres (le black hat), il a un pouvoir potentiellement immense. Or le trou qui me sert de prétexte pour écrire cette entrée, il semble que certains le connaissaient depuis deux ou trois ans et le gardaient pour eux (et il est probable que l'auteur de l'exploit en ait un bon nombre d'autres comme ça sous le coude).
La moindre des choses, je trouve, ce serait d'essayer de faire une estimation du nombre de trous de sécurité de cet ordre qui existent actuellement dans Linux. Je pense qu'on doit pouvoir y arriver avec des statistiques assez élémentaires : en regardant l'âge de chaque bout de code au moment où un trou est découvert dedans, on doit pouvoir estimer le temps moyen qu'un trou survit avant d'être détecté et corrigé — et on pourra alors estimer le nombre typique de trous par ligne de code, et donc le nombre de trous total dans Linux (il faudra sans doute faire des stats un peu plus fines parce que toutes les lignes de code ne sont pas équivalentes, mais toujours est-il que c'est possible, et ce serait un travail intéressant à refiler à un étudiant ou stagiaire, je devrais y réfléchir).
Y a-t-il une lueur d'espoir ? Il me semble en effet que la
meilleure — ou plutôt la moins mauvaise — réponse que nous ayons pour
l'instant trouvé aux trous de sécurité, ce sont les mécanismes de
cloisonnement (sandboxing) en tous genres :
c'est-à-dire tout ce qui permet d'ajouter de nouvelles barrières de
sécurité, et notamment de donner le moins de permissions possibles aux
programmes auxquels on n'a pas la plus grande confiance, ou dont ils
n'ont pas besoin (par exemple, le trou dont je parle initialement
repose sur l'utilisation de l'appel système
exotique sys_perf_event_open() : et il y a beaucoup à
dire sur le fait qu'on ne devrait pas donner à quelque programme ou
utilisateur que ce soit le droit de faire un appel système sortant des
appels Unix traditionnels sans une bonne raison).
Malheureusement, les mécanismes de cloisonnement souffrent de beaucoup
de problèmes d'utilisabilité : mettre en place une machine virtuelle
est encore lourd et pénible (quand le BIOS de
votre portable ne vous l'interdit
pas tout simplement), et pour ce qui est de cloisonnements moins
lourds, même si ce genre
d'outil a l'air extrêmement utile et prometteur, ça reste encore
très difficile et mal supporté de faire quelque chose d'aussi simple
que lancer un processus sous-privilégié sous Linux.