Sécurité IT : qui a les clés de Linux ?

Matricule : CVE-2016-0728. Nature : faille de sécurité dans le noyau Linux. Particularité : affecterait plusieurs dizaines de millions de PC et de serveurs… ainsi que les deux tiers des terminaux Android.

La start-up israélienne Perception Point attire l’attention sur cette vulnérabilité qu’elle a récemment repérée et qui fait aujourd’hui l’objet d’un correctif.

Touchant toutes les versions du kernel à partir de la 3.8, elle existerait depuis 2012. S’il n’est pas certain qu’elle ait été activement exploitée, il est vivement recommandé de ne pas attendre pour appliquer le patch au regard des risques encourus.

En effet, quiconque parvient à s’engouffrer dans la brèche peut procéder à une élévation de privilèges pour acquérir, à partir d’une simple session utilisateur, des droits de niveau administrateur (passage en root). À une condition toutefois, et pas des moindres : disposer d’un accès direct à la machine visée, par exemple via une application malveillante.

Où sont les clés ?

Le problème se trouve au niveau du gestionnaire de trousseaux de clés, ce coffre-fort sécurisé qui permet de ne pas stocker en clair les mots de passe, clés de chiffrement, certificats et autres données d’identification sensibles.

Les différents programmes peuvent accéder à ces informations à travers plusieurs interfaces : add_key, request_key et keyctl.

Chaque processus exécuté peut créer un trousseau pour la session en cours et éventuellement lui assigner un nom.

Ce trousseau peut être utilisé par d’autres processus à condition qu’ils l’appellent par le nom qui lui a été attribué.

Si on tente d’associer un nouveau trousseau à un processus, l’ancien est écrasé.

Enfin, lorsqu’un trousseau est partagé par plusieurs processus, son compteur interne (« refcount ») est incrémenté d’une unité, la valeur étant stockée dans le champ usage.

Erreur 2

Le problème se pose quand un processus fait la jonction avec un trousseau qui lui est déjà attribué. Dans ce cas, l’exécution de la routine passe au label error2, qui saute l’appel à la commande key_put et laisse fuiter des données liées à la variable usage.

Mais ce n’est pas tout, selon Perception Point : l’objet usage est de type atomic_t ; c’est-à-dire un entier codé sur 32 bits. Or, tout entier peut théoriquement être abusé pour créer un dépassement de capacité mémoire. D’autant plus qu’avec le noyau Linux, aucune vérification n’est effectuée pour empêcher des valeurs « impossibles » comme 0 (zéro).

Bilan (synthétique ; plus d’informations techniques ici) : il est possible de leurrer le kernel en lui faisant croire qu’un objet n’est plus exploité et qu’il peut ainsi libérer la zone mémoire qui lui est associée. Il suffit ensuite d’allouer cette même zone à un nouvel objet pour entraîner une corruption (technique appelée « use-after-free ») qui suffit à exécuter du code.

Le risqué posé par la faille est en théorie amoindri par les fonctions SMEP (Supervisor Mode Execution Protection) et SMAP (Supervisor Mode Access Protection), qui limitent les interactions entre le noyau et l’environnement utilisateur. Sur Android, le rempart s’appelle SELinux, qui permet de définir une politique de contrôle d’accès obligatoire aux éléments d’un système.

Crédit photo : Mclek – Shutterstock.com