Discussion :

[Patrick Ruiz]

Linux : une faille de sécurité a été détectée dans sudo
Mais a déjà été corrigée sur Red Hat, SUSE et Debian

Le système d’exploitation Linux est, de par sa conception, réputé pour être robuste. Il n’en demeure pas moins soumis aux règles du test de logiciels dont l’une stipule que l’absence de failles est une utopie. Des chercheurs en sécurité de la firme Qualys ont découvert une faille de sécurité importante dans sudo, une commande Linux bien connue qui permet de réaliser des actions avec des droits administrateur. La faille, révélée hier est déjà corrigée.

Sudo, pour « substitute user do », est une commande très célèbre de l’univers Linux/Unix. Elle permet de déclencher des actions spécifiques en mode « super utilisateur » sans qu’il soit nécessaire de se connecter au compte dédié, celui dénommé « root ». Il faut cependant noter que, dans ces conditions, les droits sont alors accordés de manière temporaire, ce, après validation du mot de passe.

Les chercheurs de Qualys Security ont publié que les versions 1.8.6p7 à 1.8.20 de la commande étaient toutes touchées par une faille de sécurité « sévère », exploitable localement. La faille référencée CVE-2017-1367 concerne toutes les distributions de Linux qui ont le module Security-Enhanced Linux (SELinux) activé.

Le souci réside dans la fonction « get_process_ttyname() », c’est-à-dire dans la façon dont sudo analyse les informations tty présentes dans le fichier de statut des processus. L’usage de cette fonction peut être détourné par un utilisateur local : via une commande spécifique incluant des espaces que la commande sudo ne dénombre pas, ce dernier peut contourner les protections habituelles et obtenir des droits complets, lui permettant alors de réaliser d’autres actions.

Les éditeurs des distributions majeures ont déjà publié des mises à jour. C’est par exemple le cas de Red Hat, qui a publié hier des correctifs pour les versions 6 et 7 de Red Hat Enterprise Linux (RHEL). Il en est de même pour SUSE et Debian, qui a mentionné les versions Wheezy, Jessie et Sid comme étant à jour via la publication y relative. La balle est donc maintenant dans le camp des utilisateurs à qui il n’est plus nécessaire de préciser qu’il faut télécharger au plus vite les versions mises à jour de leurs systèmes d’exploitation pour se mettre à l’abri.

Sources : Qualys, Red Hat, Debian, SUSE

Et vous ?

Qu’en pensez-vous ?

Voir aussi :

Linux secoué par une faille de sécurité critique dans glibc, Ghost permet de prendre le contrôle d'un système affecté
Linux : une faille dans l'outil de chiffrement de partitions Cryptsetup permet d'obtenir un accès root sur certaines machines
Une faille zero day vient d'être découverte dans le noyau Linux, la vulnérabilité affecte les versions 3.8 et supérieures de Linux Kernel
Linux et Unix affectés par une faille critique dans Bash, la vulnérabilité pourrait constituer une plus grande menace que Heartbleed

[frp31]

SElinux est une mauvais efaçon de faire du hardenning...

dans le sens ou ça encourrage à ne pas faire le hardennig "de base" ....

dans tous les cas le correctif va arriver....

[BufferBob]

tl;dr: le fichier /proc/self/stat est exporté par le noyau et a le format suivant :

Code :

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

1
2
$ cat /proc/self/stat
2750 (cat) R 29846 2750 29846 34819 2750 4202496 103 0 0 0 0 etc.

en vert ce que sudo essaye de récupérer, en rouge le nom du binaire qui s'exécute

le problème étant que sudo pour récupérer la valeur qui l'intéresse split sur l'espace et récupère le 7ème champ, sauf que si le nom de fichier contient un espace lui aussi, c'est non plus le 7ème mais le 8ème champ qu'il faudrait récupérer, et c'est là que le tipiak s’engouffre

pour parser correctement le fichier une solution (celle du patch) consiste donc à prendre le fichier par la fin et chercher la dernière parenthèse fermante ), à partir de là on est certain de n'avoir plus qu'une lettre et des chiffres, donc on peut retourner sur notre split du départ

dans le principe c'est une erreur vraiment idiote, le nom de fichier est contrôlable par l'utilisateur, on ne fait jamais "confiance" à une saisie utilisateur, le dev devait être bourré ce jour là...

[disedorgue]

Sauf que j'ai un doute sur le patch:

Code :

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
#include <stdio.h>
#include <string.h>
 
int main ()
{
   char *str;
 
   str = strrchr("(foo)bar) tipiak", ')');
 
   printf("Apres dernier ')': '%s'\n", str);
 
   str = strrchr("(foo)bar\0) tipiak", ')');
 
   printf("Apres dernier ')': '%s'\n", str);
 
   return(0);
}

donne:

Code :

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

1
2
3
$ ./a.out
Apres dernier ')': ') tipiak'
Apres dernier ')': ')bar'

[BufferBob]

Code :

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

str = strrchr("(foo)bar\0) tipiak", ')');

non l'octet nul c'est la dernière limite, on peut pas avoir de zéro dans un nom de fichier, par contre maintenant que tu m'y fais penser rien n'empêche d'avoir un retour à la ligne...

Code :

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

1
2
3
4
5
6
$ ln -s /bin/cat $'foo
> bar'
$ './foo
bar' /proc/self/stat
19658 (foo
bar) R 29846 19658 29846 34819 ...

et comme dans le code il part du principe que le fichier ne contient qu'une seule ligne, il fait un unique getline() pour récupérer la string, la vuln est toujours présente, exclusivité developpez.com

edit: ou... pas https://www.sudo.ws/repos/sudo/rev/9ad60fe663e5 j'avoue y avoir cru un peu tout au long de la journée

[Jonyjack]

Pas vraiment, puisque le code est :

Code :

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

1
2
char *cp = strrchr(line, ')');
if (cp != NULL) { /* PARSE */ }

Donc si un retour à la ligne est présent, "cp" vaut NULL et la fonction ne récupère rien.

[hotcryx]

on peut pas avoir de zéro dans un nom de fichier

hein! Pourtant parfois j'ajoute la date de l'année et le 0 passe

[disedorgue]

Pas vraiment, puisque le code est :

Code :

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

1
2
char *cp = strrchr(line, ')');
if (cp != NULL) { /* PARSE */ }

Donc si un retour à la ligne est présent, "cp" vaut NULL et la fonction ne récupère rien.

Et dans ce cas ?

Code :

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

1
2
3
4
5
6
$ ln -s /bin/cat $'foo) 1 2 3 4
> bar'
$ './foo) 1 2 3 4
bar' /proc/self/stat
3280 (foo) 1 2 3 4
ba) R 2211 3280 2211 34816 3280 4202496 183 0 0 0 0 0 0 0 20 0 1 0 1722067 103358464 135 18446744073709551615 4194304 4235780 140733624854576 140736343925928 258466494256 0 0 0 0 0 0 0 17 0 0 0 0 0 0

Une autre revision du patch (voir l'Edit de BufferBob), montre que la protection est surtout sur le fait que l'on ne peut plus traverser /dev

Mais bon, j'espère que le jour ou coté kernel linux, ils changeront le format de cette ligne, ils penseront à réadapter sudo...

[BufferBob]

Et dans ce cas ?

Code :

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

1
2
$ ln -s /bin/cat $'foo) 1 2 3 4
> bar'

yep c'est ça, à noter d'ailleurs que sur les noyaux récents (4.x pour le moins) le progname est tronqué à 16 char apparemment (du coup la variante aurait consisté à ne pas mettre les 1,2,3,4 mais seulement les espaces pour que ça fonctionne)