CVE-2022-1015 & CVE-2022-1026

Ce README.md est une traduction du blog de David. David a trouvé les CVE 1015 et 1016 dans le noyau Linux. Vous pouvez visiter sa page web pour lire le document original.

Voici ses réseaux sociaux :

• Twitter
• Github

Une analyse des deux nouvelles vulnérabilités Linux dans nf_tables

Publié le 2 avril 2022.

• CVE-2022-1015 permet un accès hors limites (out-of-bounds) causé par de faibles validations des arguments d'entrée, pouvant conduire à l'exécution de code à distance et à une élévation de privilèges locale.
• CVE-2022-1016 est lié à une mauvaise initialisation des variables stockées sur la stack, ce qui peut être utilisé pour fuiter une grande variété de données du noyau vers l'espace utilisateur (userspace).

Ces problèmes devraient être exploitables dans les configurations par défaut des versions les plus récentes d'Ubuntu et de RHEL. J'ai écrit ma preuve de concept (PoC) pour le CVE-2022-1015 en ciblant la version 5.16-rc3 du noyau d'Arch Linux.

Ce document s'adresse aux personnes ayant une connaissance de base du noyau Linux en termes de fonctionnalité et de sécurité. J'ai essayé de rendre ce document accessible aux personnes qui n'ont pas de connaissances sur la stack réseau afin de le rendre accessible à tous.

Voici un guide de lecture :

• Si vous êtes ici simplement pour lire à propos de la vulnérabilité, commencez à la Section 4
• Si vous voulez aussi un peu de contexte sur le sous-système du noyau, commencez par la Section 2
• Si vous êtes intéressé par un peu plus de contexte, lisez l'intégralité du document

1. Contexte

À la mi-février, le programme de sécurité de Google a annoncé qu'il poursuivrait son programme de primes kCTF, offrant des récompenses allant de 31 337 $ à 91 337 $ pour un exploit du noyau Linux capable d'élever les privilèges jusqu'à l'utilisateur root depuis des processus sans privilèges dans un sandbox nsjail.

Étant un pauvre étudiant, cela a évidemment attiré mon attention. C'était ma première fois à la recherche d'une vulnérabilité du « monde réel », mais lors de mes aventures à jouer au CTF avec mon équipe, je me suis familiarisé avec le noyau Linux en termes de sécurité. Après des heures et des heures avec très peu de progrès, voire aucun (mais avec une meilleure connaissance de Linux), j'ai réussi à trouver quelques vulnérabilités dans le module nf_tables.

Malheureusement, en fin de compte, je me suis rendu compte que ce module n'était pas présent dans les règles du kCTF de Google (donc je n'ai obtenu aucune récompense pour ces deux vulnérabilités). Mais évidemment, je les ai quand même signalées et j'ai écrit un exploit LPE (élévation de privilèges locale) pour le CVE-2022-1015.

1.1 Identification de la cible et stratégie d'audit

Bon, vous avez donc décidé que vous allez trouver des vulnérabilités dans Linux. Et maintenant ? Linux est un projet gigantesque, et il est assez facile de ne pas voir la forêt à cause des arbres (vous vous concentrez tellement sur les détails que vous perdez de vue ce qui est vraiment important, vous n'avez pas une vue d'ensemble de la situation). Pour aggraver les choses, de nombreuses parties ne sont pas documentées et vous devez lire beaucoup de code pour comprendre ce qui se passe.

J'ai commencé par essayer d'avoir une perspective détaillée du modèle de sécurité de Linux. Trouver un bug est une chose ; mais trouver un bon bug en est une autre très différente. Après tout, tous les bugs ne sont pas créés égaux :

• Si un bug nécessite des privilèges root, il n'existe pas de limite de sécurité significative (à moins que la signature des modules du noyau (kernel module signing) ne soit activée)
  • Parmi les choses qui me viennent à l'esprit, il y a beaucoup de modules de systèmes de fichiers (virtuels). Seul l'utilisateur root initial peut monter ces systèmes de fichiers. L'exception repose sur vfe qui spécifie FS_USERNS_MOUNT, auquel cas vous pouvez les monter dans le user namespace.
• Si l'on ne peut pas accéder à un bug via les appels système, il ne sera probablement pas exploitable.
  • Cela s'applique à de nombreux pilotes matériels, car vous n'avez pas d'accès physique à la machine. Les pilotes réseau de bas niveau pourraient néanmoins être une bonne cible si vous pouvez, p. ex., envoyer des données via Bluetooth ou 802.11.ac.
  • Évidemment, cela dépend du scénario dans lequel vous vous trouvez.
• De nombreux bugs nécessitent CAP_SYS_ADMIN ou CAP_NET_ADMIN.
  • Les user namespaces sont activés par défaut, donc ce n'est pas un problème.
  • Sinon, vous devrez d'abord élever vos privilèges vers le namespace de l'utilisateur root dans un conteneur.
• Tous les modules ne seront pas présents sur votre cible.
  • Linux est un logiciel exceptionnel hautement configurable, donc toutes les configurations peuvent varier d'une multitude de façons.
  • La configuration du noyau est généralement accessible depuis /proc/config.gz. Les modules peuvent être compilés en tant que modules (=m) ou compilés séparément et chargés au moment de l'exécution (=y).
  • Vous pouvez utiliser /proc/modules et /proc/kallsyms, mais ils ne sont pas toujours fiables, car les modules peuvent être chargés dynamiquement dans le noyau (p. ex. request_module).
  • Si vous n'êtes pas sûr, écrivez un petit programme qui essaie d'interagir avec le module.

Ces restrictions nous aident à connaître les limites des sous-systèmes dans lesquels nous pouvons chercher des vulnérabilités. Je pense que c'est une bonne idée de prendre votre temps pour essayer de planifier votre attaque contre la cible de votre choix.

J'ai appris ma leçon sur le point précédent. Comme je l'ai mentionné, le module nf_tables n'était pas chargé dans l'instance que kCTF nous a présentée. J'aurais pu m'en rendre compte dès le début et m'épargner la déception :p. D'un autre côté, vous ne seriez probablement pas en train de lire ce blog en ce moment si je m'en étais rendu compte plus tôt ; je suppose que les choses ont bien tourné après tout.

Une explication de la raison pour laquelle le COS, fork Linux optimisé pour les conteneurs de Google, n'avait pas nf_tables peut être trouvée ici et ici.

1.2 nf_tables : pourquoi ?

Après avoir évalué les points mentionnés précédemment, j'ai décidé que ma meilleure route pour commencer serait probablement de regarder le code source réseau. De nombreuses fonctionnalités intéressantes y nécessitent CAP_NET_ADMIN, mais comme je l'ai mentionné, ce n'est en réalité pas un problème. Au contraire, je soupçonne que les composants qui nécessitent des capacités spéciales sont généralement moins sécurisés, car les développeurs du noyau peuvent avoir un faux sentiment de sécurité.