Use-After-Free dans Netfilter nf_tables lors du traitement de requêtes par lots

Détails de la vulnérabilité

Le code affecté provient du noyau Linux officiel depuis https://kernel.org/ et fait partie du composant Netfilter nf_tables (net/netfilter/nf_tables_api.c).

Netfilter nf_tables permet de mettre à jour sa configuration sous forme d'opération atomique. Lors de l'utilisation de cette fonctionnalité, les clients en mode utilisateur envoient des requêtes par lots contenant une liste d'opérations de base. Netfilter nf_tables traite alors toutes les opérations du lot comme une seule transaction. Lors du traitement du lot, Netfilter nf_tables vérifie les mises à jour de l'état de la configuration pour s'assurer que chaque opération de base successive est valide, et cela prend également en compte les mises à jour d'état de toutes les opérations précédentes du lot. Cependant, la vérification actuellement implémentée est insuffisante.

Dans notre scénario spécifique, nous partons d'une configuration Netfilter nf_tables qui possède une nft_rule avec une expression lookup sur un nft_set anonyme, et où le nft_set anonyme contient certains éléments. Ensuite, nous envoyons une requête par lots contenant les deux opérations de base suivantes :

1. Opération NFT_MSG_DELRULE pour supprimer la nft_rule.
   Notez que cela supprime également implicitement l'expression lookup et le nft_set anonyme.
2. Opération NFT_MSG_DELSETELEM pour supprimer l'un des éléments du nft_set anonyme supprimé.

La version actuelle de Netfilter nf_tables accepte la requête par lots ci-dessus. Elle appelle ensuite nf_tables_commit_release() qui ajoute les ressources libérées à nf_tables_destroy_list. La nf_tables_destroy_list est ensuite traitée par nf_tables_trans_destroy_work() qui commence par désallouer les ressources liées à l'opération NFT_MSG_DELRULE en appelant :

nft_commit_release()
    nf_tables_rule_destroy()
        nf_tables_expr_destroy()
            expr->ops->destroy() qui pointe vers nft_lookup_destroy()
                nf_tables_destroy_set()
                    nft_set_destroy()
                        kvfree() qui désalloue la mémoire utilisée par `nft_set`

avant de traiter l'opération NFT_MSG_DELSETELEM, où une référence au nft_set désalloué est accédée via nft_trans_elem_set() lors des appels suivants :

nft_commit_release()
    nf_tables_set_elem_destroy()
        nft_set_elem_ext()

Dans nft_set_elem_ext() ci-dessus, l'emplacement mémoire du nft_set désalloué est accédé pour déterminer l'emplacement de nft_set_ext :

static inline struct nft_set_ext *nft_set_elem_ext(const struct nft_set *set,
                                                   void *elem)
{
        return elem + set->ops->elemsize;
}

pour les opérations qui suivent. Ainsi, lorsque la valeur de set->ops->elemsize est corrompue, un emplacement mémoire inattendu peut être interprété comme une liste de nft_expr à détruire :

static void nf_tables_set_elem_destroy(const struct nft_ctx *ctx,
                                       const struct nft_set *set, void *elem)
{
        struct nft_set_ext *ext = nft_set_elem_ext(set, elem);

        if (nft_set_ext_exists(ext, NFT_SET_EXT_EXPRESSIONS))
                nft_set_elem_expr_destroy(ctx, nft_set_ext_expr(ext));

Techniques d'exploitation

Exploiter la vulnérabilité ci-dessus nécessite de gagner une course avec nf_tables_trans_destroy_work() qui s'exécute à partir d'un thread de travail en arrière-plan du noyau Linux. Cela semble compliquer l'exploitation pratique, même avant de prendre en compte les mitigations existantes, telles que le renforcement de l'allocateur de slabs du noyau, l'Address Space Layout Randomization (KASLR) et surtout l'Intégrité du Flux de Contrôle. Cependant, le PoC joint prouve qu'il est toujours possible d'obtenir une exploitation raisonnablement fiable en pratique.

Afin d'exploiter la vulnérabilité, nous devons modifier le contenu de la mémoire du nft_set après qu'il a été désalloué sous nf_tables_rule_destroy(), mais avant qu'il ne soit utilisé sous nf_tables_set_elem_destroy(). Les deux nf_tables_rule_destroy() et nf_tables_set_elem_destroy() sont appelées dans une seule invocation de nf_tables_trans_destroy_work() qui s'exécute à partir d'un thread de travail en arrière-plan du noyau Linux. De plus, le bloc mémoire désalloué n'est généralement disponible pour réutilisation que sur le même cœur de CPU.

En faisant la course avec nf_tables_trans_destroy_work(), nous améliorons nos chances en ajoutant un délai contrôlé pour le thread de travail en arrière-plan entre ses appels à nf_tables_rule_destroy() et nf_tables_set_elem_destroy(). Pour cela, nous insérons une opération supplémentaire pour détruire un autre nft_set contenant un grand nombre d'éléments. De plus, nous maintenons tous les autres cœurs de CPU occupés, de sorte que le thread de travail en arrière-plan soit susceptible d'être planifié sur un cœur de CPU spécifique, afin de pouvoir tenter d'allouer une nouvelle structure depuis le même cœur de CPU juste après avoir désalloué nft_set sous nf_tables_rule_destroy(). Notre objectif est d'allouer un nouveau nft_set de type différent pour réutiliser l'emplacement mémoire du nft_set désalloué sous nf_tables_rule_destroy().

Le nouveau type de nft_set est choisi pour utiliser une valeur différente pour set->ops->elemsize. Ainsi, lorsque le thread de travail en arrière-plan appelle finalement nf_tables_set_elem_destroy() pour traiter l'opération NFT_MSG_DELSETELEM, il interprète son argument elem de manière incorrecte, de sorte que le nft_set_ext *ext corrompu se trouve quelques octets après l'emplacement correct. Cela signifie que certains champs de données contrôlés par l'utilisateur du nft_set_ext original sont désormais interprétés comme des en-têtes, entraînant une confusion de type.

Une façon d'abuser de cette confusion de type est de fabriquer les en-têtes nft_set_ext corrompus avec des valeurs de décalage telles que nf_tables_set_elem_destroy() interprète le contenu de tout bloc mémoire adjacent comme la liste des nft_expr à détruire via les appels suivants :

nft_set_elem_expr_destroy()
    __nft_set_elem_expr_destroy()
        nf_tables_expr_destroy()
            expr->ops->destroy()

À ce stade de l'exploitation, nous n'avons pas encore de détails sur la disposition de la mémoire du noyau. Il n'est donc pas possible de fabriquer des adresses de pointeur absolues. Cependant, lors de la fabrication des en-têtes nft_set_ext corrompus, nous pouvons toujours utiliser des décalages hors limites, de sorte que expr->ops->destroy() soit appelé sur certains nft_expr valides dans les blocs mémoire adjacents.

Pour cela, nous pulvérisons des expressions nft_log, avec un NFTA_LOG_PREFIX contrôlé. Ce nft_log->prefix est ensuite désalloué par nft_log_destroy() une fois que expr->ops->destroy() est appelé :

static void nft_log_destroy(const struct nft_ctx *ctx,
                            const struct nft_expr *expr)
{
        struct nft_log *priv = nft_expr_priv(expr);
        struct nf_loginfo *li = &priv->loginfo;

        if (priv->prefix != nft_log_null_prefix)
                kfree(priv->prefix);

Notez que nous pouvons toujours accéder et même désallouer à nouveau cette mémoire via l'autre référence provenant de l'expression nft_log pulvérisée.

De plus, nous pouvons également contrôler la taille de nft_log->prefix, de sorte qu'elle puisse être allouée depuis n'importe quel slab kmalloc-{8, ..., 192}. Enfin, la mémoire référencée est interprétée comme une chaîne de caractères par le noyau, donc pas besoin de se soucier des corruptions lorsque nous superposons différents objets dessus. C'est essentiellement la fin du jeu.