Discussion :

[Olivier Famien]

Une faille permet de contourner le système d’authentification du programme d’amorçage Grub2 de Linux
en appuyant 28 fois sur la touche retour arrière

En matière de sécurité, il n’existe pas de système dénué de bogues. Tous les systèmes aussi bien libres que propriétaires ont déjà connu à maintes reprises des failles de sécurité à divers niveaux. En considérant ce fait, Linus Torvalds admettait à la dernière conférence LinuxCon 2015 qu’il n’existe pas de sécurité au sens parfait. Les développeurs et utilisateurs devront donc considérer une occurrence de vulnérabilité comme un simple bogue qu’il faut traiter.

Tout récemment, c’est le système d’exploitation Linux qui a laissé entrevoir une faille au niveau de son programme de démarrage. En effet, après avoir mené des analyses approfondies sur ce système, deux chercheurs du nom de Hector Marco et Ismael Ripoll travaillant pour Cybersecurity Group ont découvert un bogue dans le programme GRUB2 qui permet de gérer toutes les étapes de démarrage de Linux jusqu’à ce que l’interface utilisateur soit opérationnelle.

Il faut souligner que Grub2 est une réécriture de Grub qui permet de charger les partitions amorçables afin de permettre aux utilisateurs de choisir au démarrage le système d’exploitation qu’ils désirent utiliser lorsqu'il y a plusieurs systèmes installés sur le matériel. Pour plus de sécurité, il est possible de verrouiller l’accès au Grub afin que ce dernier demande un mot de passe au démarrage du système. Cela permet d'éviter l'édition du Grub pour en prendre le contrôle.

Aussi, lorsque Linux démarre et que Grub demande le nom d’utilisateur et le mot de passe, si vous appuyez sur la touche retour arrière 28 fois, la machine redémarre ou vous donne accès à la console Grab rescue. Cela constitue un bogue que pourraient utiliser des individus mal intentionnés pour effectuer toutes sortes d’actions malveillantes sur le système poreux. Cela part du contrôle du GRUB en lui-même au déni de service en passant par la copie des informations disponibles sur le système une fois le système d’authentification contourné.

Selon les chercheurs, cette faille est générée par un problème détecté sur une variable qui occasionne un débordement de mémoire. En principe lorsque les utilisateurs tentent de s’authentifier au démarrage, la mémoire non utilisée par l'entrée est mise à zéro. Cela permet d'éviter l'injection de données. Toutefois, la fonction calculant la taille du tampon entré par l'utilisateur n'est pas sans faille :

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
static int
grub_username_get (char buf[], unsigned buf_size)
{
  unsigned cur_len = 0;
  int key;
 
  while (1)
    {
      key = grub_getkey ();
      if (key == '\n' || key == '\r')
        break;
 
      if (key == '\e')
        {
          cur_len = 0;
          break;
        }
 
      if (key == '\b')  // Does not checks underflows !!
        {
          cur_len--; // Integer underflow !!
          grub_printf ("\b");
          continue;
        }
 
      if (!grub_isprint (key))
        continue;
 
      if (cur_len + 2 < buf_size)
        {
          buf[cur_len++] = key; // Off-by-two !!
          grub_printf ("%c", key);
        }
    }
 
  grub_memset( buf + cur_len, 0, buf_size - cur_len); // Out of bounds overwrite
 
  grub_xputs ("\n");
  grub_refresh ();
 
  return (key != '\e');
}

Comme on peut le voir, à chaque retour de charriot (caractère '\b'), la taille du tampon est décrémentée. C'est logique, mais que se passe t-il si la taille est déjà de zéro ? Elle provoquera un décalage en arrière du pointeur buf utilisé dans l'appel à grub_memset() final et va donc écrire des zéros sur une zone mémoire bien plus grande que ce qui pouvait être prévu.

En écrivant des zéro dans la mémoire de Grub2, il sera possible soit redémarrer le système ou encore, d'écraser les tampons contenant le nom de l'utilisateur et son mot de passe en mémoire. Ainsi, vous pouvez accéder à la console et configurer Grub2 pour démarrer comme bon vous semble.

Cette vulnérabilité a été référencée sous le code CVE-2015-8370 et a été catégorisée comme une faille de sévérité moyenne. Elle est présente dans le programme Grub à partir de la version 1.98 jusqu’à la version 2.02 dont la dernière mise à jour est disponible depuis le début de ce mois de décembre. Nous rappelons, en outre, que GRUB2 est utilisé sur la plupart des systèmes Linux et certains systèmes embarqués. Il est donc probable que bon nombre de systèmes en soient affectés.

Mais une condition qui limite les dégâts est que cette faille n’est exploitable que localement. Par ailleurs, les chercheurs ont sorti un correctif d'urgence pour corriger les failles découvertes sur les différentes distributions.


Source : Page de présentation de faille découverte

Et vous ?

Que vous inspire la découverte de faille ? Êtes-vous inquiets pour la sécurité sur Linux ?

Voir aussi

Forum Sécurité

[TiranusKBX]

Il est vrai qu'il n'y a pas lieux de s'alarmer sauf si l'on travail avec un PC portable ayant accès à des données sensibles

[zippedfire]

Euh ce serait pas Linus Torvalds plutôt
(y'a écrit Linux Torvalds)

[herzleid]

Il est vrai qu'il n'y a pas lieux de s'alarmer sauf si l'on travail avec un PC portable ayant accès à des données sensibles

Même pas. En général, l'authentification est réalisée au niveau de l'OS, pas du bootloader. A la limite, on va utiliser un mot de passe au niveau du bios.

Si vraiment il y a des données confidentiel, on va utiliser des dossiers voir des partition chiffrées.

Si le supposé attaquant arrive au clavier de la machine, il lui sera plus facile d'utiliser un livecd/liveUsb.

C'est le genre de faille qui ne doit pas affecter grand monde !

[BufferBob]

reste que contourner une sécurité en appuyant 30x sur la touche backspace c'est quand même tout moisi

[Invité]

28 fois BACKSPACE pour accéder à la console Grub2.

Ca m'a laissé pantois
On dirait presque une fonctionnalité

Steph

[Danny-k]

Comme on peut le voir, à chaque retour de charriot (caractère '\b'), la taille du tampon est décrémentée. C'est logique, mais que se passe t-il si la taille est déjà de zéro ? Elle deviendra négative et le grub_memset() final va écrire des zéro sur une zone mémoire bien plus grande que ce qui pouvait être prévu.

La variable curr_len, est non signé, et dans ce cas elle ne devient pas négative mais prends la valeur UINT_MAX, d'où le memset qui va écrire un peu trop loin.

1. [...] A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. (ISO/IEC 9899:1999 (E) §6.2.5/9)

[LittleWhite]

La formulation n'est pas correcte directement, c'est possible. Mais même si vous avez un unsigned int et que vous l'utilisez dans une addition comme dans l'exemple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#include <stdio.h>
 
int main()
{
	int a = 10;
	unsigned int b = -2;
	printf("%d\n",a+b);
}

Vous obtenez 8.

[Danny-k]

La formulation n'est pas correcte directement, c'est possible. Mais même si vous avez un unsigned int et que vous l'utilisez dans une addition comme dans l'exemple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#include <stdio.h>
 
int main()
{
	int a = 10;
	unsigned int b = -2;
	printf("%d\n",a+b);
}

Vous obtenez 8.

Premièrement l'exemple est biaisé, vu que c'est un %d, donc il y a un cast implicite vers un entier signé. Ensuite les valeurs choisies sont mal choisies, puisque si on choisi d'autres valeurs un peu plus petite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#include <stdio.h>
 
int main()
{
	int a = 1;
	unsigned int b = -2;
	printf("%u\n",a+b);
}

Vous obtenez 4294967295 et non plus -1, si ça avait été %d à la place.

De plus dans le code, il n'y a pas de printf, mais juste un opérateur de décrémentation, ce qui fait que la valeur n'est pas négative une fois en dessous de 0, mais bel et bien toujours positive.

[LittleWhite]

Sauf que la valeur cur_len, à la fin, sera utilisé dans le memset. Le résultat de l'addition déplacera le pointeur en arrière du tampon buf (dans le sens, plus haut dans la mémoire).
Votre cas est biaisé, car votre printf() force l'affichage en unsigned. Mais si vous le forcez en int, vous obtenez -1.
Dans mon exemple, si vous faites un printf() pour afficher un unsigned vous obtenez 8 aussi. Donc mon exemple est moins biaisé. Car quelque soit l'affichage, vous aurez un calcul de 10 + (-2) et cela quelque soit l'affichage. Et c'est ce qui arrive dans le code de grub, vous avez une soustraction, là ou normalement vous ne devriez pas et ce n'est pas un unsigned qui vous en protègera.