Bug Linux à la racine : découvrez le mot de passe secret !

Cybersécurité
Root

Des experts en cybersécurité espagnoles viennent de révéler un bug Linux à la racine, qui a de quoi faire grincer les dents !

Plus précisément, et juste au cas où nous provoquions inutilement la colère des fans de Linux ici, il ne s’agit pas d’un bug Linux (ou pour être plus précis un bug GNU/Linux), car le problème se situe plutôt au niveau de l’un des scripts de démarrage, utilisé dans beaucoup d’autres distributions, et non au niveau du noyau lui-même, ou encore au niveau des utilitaires majeurs.

Il s’agit aussi, pour être franc, d’un bug Linux pas forcément dangereux, si l’on peut parler encore d’un bug, car il peut être exploité uniquement si :

  • Vous avez un accès physique à l’ordinateur.
  • Le système de partition (et probablement le reste de l’ordinateur aussi) est chiffré.
  • Vous n’avez pas saisi, de manière délibérée, le bon mot de passe pour le déchiffrement.

Lorsque vous déclenchez ce bug Linux, vous vous retrouvez dans un root shell épuré, avec un accès à la partition /boot uniquement.

Si vous êtes en train de forcer l’ordinateur sans surveillance de quelqu’un, il ne s’agit pas d’un obstacle insurmontable, car vous pourrez sans aucun doute aller plus loin en utilisant l’un de ces fameuses clé USB que tous les sysadmins ont dans leur poche, et ce à chaque instant !

Et si vous essayez de vous connecter à la racine à partir de l’une de ces bornes internet, où le clavier et l’écran sont visibles mais par contre tout le reste est sécurisé avec un cadenas, le disque dur n’a certainement pas été protégé en utilisant un chiffrement total du disque, ce qui signifie que cette vulnérabilité n’est pas accessible.

La raison pour laquelle le chiffrement total du disque doit être activé est que ce bug Linux, permettant de contourner le mot de passe, se situe de manière gênante …

… dans le script qui vous demande de saisir le mot de passe d’accès à votre disque dur.

Il s’avère que tout ce que vous avez à faire est de saisir un mauvais mot de passe une centaine de fois, et le tour est joué !

bug-linuxEn réalité, vous pouvez juste presser [Enter] et maintenir la touche enfoncée jusqu’à ce le système commence à répéter l’action automatiquement, et après une bonne minute vous atterrissez sur une fenêtre de récupération du système.

bug-linuxLe code d’erreur est très intéressant, car il nous donne une leçon des plus utiles : lorsque que vous recevez une erreur en provenance d’un élément en bas de la chaîne, il est important de savoir pourquoi cette erreur est apparue, plus que le simple fait qu’elle soit apparue.

Comme l’ont souligné les experts, dans leur article qui expliquait ce bug Linux, la fonction de validation du mot de passe se présente sous la forme ci-dessous, en utilisant un pseudo code :

function dounlock: 
   for tries = 1,3 do
      read password
      apply password to drive 
      if drive is unlocked then return OK end
   end
   return ERROR
end

Jusque-là tout va bien.

Vous vous attendez certainement à ce que la fonction dounlock soit utilisée comme ceci :

function tryunlock:
   for tries = 1,5 do
      if dounlock is OK then return OK end
      wait a while
   end
   # User didn't know the password.
   # Start from the top after a bigger delay.
   reboot computer 
end

Cependant ce n’est pas le cas.

Plus haut dans la chaîne, vous avez la fonction suivante :

function dostartup:
   for tries = 1,30 do
      . . .
      try dounlock
      # If the root device hasn't shown up yet, give it a little while
      # to allow for asynchronous device discovery (e.g. USB).
      wait a while
      if root device is unlocked then return OK end
   end
   drop to emergency root shell
end

Comme vous pouvez le voir, nous avons 2 problèmes qui s’entremêlent ici :

  • La fonction dounlock vous permet 3 tentatives, mais est autorisée à fonctionner 30 fois.
  • Lorsque les 30 tentatives sont utilisées, la raison pour laquelle l’équipement racine se retrouve non verrouillé est ignorée.

En d’autres termes, avant que les 30 tentatives se soient utilisées, les scripts de démarrage ne prennent pas en compte que vous ne connaissez pas en réalité le vrai mot de passe.

Bien sûr, ceci doit être voulu, étant donné que le root shell apparaît au niveau de l’ordinateur local, et ainsi demande un accès physique à ce dernier.

Rappelez-vous que le disque dur est chiffré dans sa totalité, ainsi un cybercriminel ne peut pas avoir facilement accès à vos données de cette manière.

Néanmoins, les distributions basées sur Ubuntu, chargent les scripts de déverrouillage du disque mentionnés ci-dessus, à partir d’une partition spéciale non chiffrée appelée /boot, qui contient les copies non chiffrées de votre noyau et, bien sûr, des fameux scripts de démarrage incriminés.

Ainsi, même s’ils ne pourront pas utiliser les ports USB pour ajouter ou extraire des donnée additionnelles, en donnant aux cybercriminels et aux autres mécréants un accès facile à la racine, ils peuvent aussi facilement saboter le processus de démarrage lui-même.

Cela signifie qu’ils pourront facilement, et plutôt discrètement, ajouter quelques lignes pour récupérer le mot de passe de votre disque la prochaine fois que vous démarrerez votre équipement.

Enfin, quoi de plus embarrassant que de donner à un hacker l’accès à un root shell aussi simplement qu’en pressant plusieurs fois sur [Enter]?

Quoi faire ?

Les distributions qui utilisent ce script problématique (nous avons essayé ElementaryOS, qui est construit sur le noyau Debian/Ubuntu) devraient décider de changer ce code, ainsi vérifier les emails provenant de votre distro.

D’autre part, ceux assurant la maintenance de ces distros, devraient aussi décider que le fait de basculer vers un shell de récupération devrait être un comportement par défaut, lorsque le système de fichiers racine ne fonctionne pas, et ce peu importe la raison.

Si cela vous pose un problème, nous avons 2 suggestions.

Un rapide contournement proposé par les auteurs de l’article, est de rajouter le paramètre de démarrage du noyau panic=10, qui signifie que le noyau redémarrera automatiquement après 10 secondes si le système panique (l’équivalant Linux d’un écran bleu Windows ou bien d’un écran gris foncé sur MacOS).

Cela fonctionne ici car le script de démarrage ci-dessus a installé le “basculement d’urgence vers un root shell” ainsi :

if kernel parameter panic is set then
   wait (panic) seconds
   reboot
else
   drop to emergency root shell
end

Si vous avez une borne internet, par exemple, vous avez certainement  l’auto-redémarrage activé, ainsi vous contournez déjà probablement le root shell non désiré.

Un meilleur contournement, mais admettons le bien plus complexe, est de configurer votre Linux bootloader, afin de déverrouiller votre disque dur plus tôt dans le processus de démarrage (le bootloader sur les systèmes basés sur Ubuntu est en général GRUB, qui intègre cette fonctionnalité).

Cette deuxième option contourne le script bogué ci-dessus, car l’équipement racine est déjà déverrouillé avant que le script ne soit lancé.

Ceci vous permet aussi d’avoir /boot chiffré par la même occasion, compliquant la tâche d’une cybercriminel ayant un accès limité et très peu de temps pour piéger votre ordinateur en modifiant le noyau, ou bien vos scripts de démarrage.

Malheureusement, la plupart des distros n’ont pas de fonctionnalité d’installation indexée sur le temps pour tout chiffrer, y compris /boot. De plus, les procédures pour le faire varient tellement d’une disto à une autre, que nous ne pouvons pas vous donner une liste d’instructions claires ici.

Bien sûr, vous pouvez basculer sur MacOS, où toutes ces procédures sont gérées pour vous au moment du démarrage…
…mais nous savons ce qu’il risque de se passer si nous faisons une telle recommandation !


Billet inspiré de Get root on Linux: learn the secret password, par Paul Ducklin, Sophos NakedSecurity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.