Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    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 ?

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent sénior
    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....

  3. #3
    Expert éminent
    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à...

  4. #4
    Expert éminent
    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'
    Cordialement.

  5. #5
    Expert éminent
    Citation Envoyé par disedorgue Voir le message
    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

  6. #6
    Membre averti
    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.

  7. #7
    Membre extrêmement actif
    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
    Si la réponse vous a aidé, pensez à cliquer sur +1

  8. #8
    Expert éminent
    Citation Envoyé par Jonyjack Voir le message
    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...
    Cordialement.

  9. #9
    Expert éminent
    Citation Envoyé par disedorgue Voir le message
    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)