Linux : une faille de sécurité a été détectée dans sudo

Version imprimable

07/06/2017, 02h33
Patrick Ruiz

Linux : une faille de sécurité a été détectée dans sudo

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 ?

:fleche: Qu’en pensez-vous ?

Voir aussi :

:fleche: Linux secoué par une faille de sécurité critique dans glibc, Ghost permet de prendre le contrôle d'un système affecté
:fleche: Linux : une faille dans l'outil de chiffrement de partitions Cryptsetup permet d'obtenir un accès root sur certaines machines
:fleche: 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
:fleche: Linux et Unix affectés par une faille critique dans Bash, la vulnérabilité pourrait constituer une plus grande menace que Heartbleed
07/06/2017, 12h21
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.... :)
07/06/2017, 17h55
BufferBob
tl;dr: le fichier /proc/self/stat est exporté par le noyau et a le format suivant :
Code:

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à...

Sauf que j'ai un doute sur le patch:

Code:

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:

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

08/06/2017, 11h14
BufferBob
Citation:

Envoyé par disedorgue

Code:

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:

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 :lol:

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 :aie:
09/06/2017, 14h27
Jonyjack
Pas vraiment, puisque le code est :
Code:

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.
09/06/2017, 15h18
hotcryx

Citation:

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 :aie:

Citation:
Envoyé par Jonyjack
Pas vraiment, puisque le code est :
Code:

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:

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...

09/06/2017, 20h51
BufferBob
Citation:
Envoyé par disedorgue

Et dans ce cas ?

Code:

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)