Une vulnérabilité dans io_uring permettait à un utilisateur sans autorisations de devenir root même dans des conteneurs

Récemment informations de vulnérabilité divulguées (CVE-2022-29582) dans l'implémentation de l'interface d'E/S asynchrones io_uring, incluse dans le noyau Linux depuis la version 5.1, qui permet à un utilisateur non privilégié de devenir root sur le système, même lors de l'exécution d'un exploit de conteneur.

Il est important de mentionner que ladite vulnérabilité a été signalée il y a un peu plus de 3 mois (environ début mai de cette année), mais l'information et la divulgation complètes n'ont été publiées que récemment.

Concernant la vulnérabilité, il est mentionné que cette se produit lors de l'accès à un bloc de mémoire déjà libéré, se manifeste dans les noyaux Linux à partir de la branche 5.10.

À propos de la vulnérabilité CVE-2022-29582

Cette vulnérabilité permet d'accéder à la mémoire libérée à la suite d'une condition de concurrence lors de la gestion des délais d'attente dans la fonction io_flush_timeouts(), quie supprime l'entrée de délai d'attente de la liste et l'annule, sans vérifier la création et la suppression du délai d'attente à ce stade.

Une description générale mise à jour de io_uring a déjà été fournie par d'autres. Ils l'expliquent mille fois mieux que nous, nous allons donc couvrir le sous-système plus en détail (voir cet article Grapl Security et cet article Flatt Security pour une excellente introduction).

Quoi de plus important, le champ opcode détermine le type d'opération à effectuer. Pour chaque "opcode" qui le requiert, le champ fd spécifie le descripteur de fichier sur lequel effectuer l'E/S demandée. Presque tous les appels système d'E/S normaux (read, sendto, etc.) ont un opcode asynchrone équivalent. Chaque champ peut jouer un rôle différent selon l'opération.

Une fois extrait de la SQ, une SQE est convertie en une représentation interne décrite par la struct io_kiocb (rappel d'entrée/sortie du noyau). Ces objets sont communément appelés requêtes.

struct io_kiocb est utilisé comme équivalent du SQE "prêt pour le lancement" sur lequel il est basé, où tout descripteur de fichier est résolu en struct file*s, les informations d'identification de l'utilisateur sont attachées, la personnalité (dans laquelle les cœurs s'exécuteront), etc. .

Une fois l'opération demandée terminée, elle est écrite dans la file d'attente d'achèvement (CQ) une entrée qui correspond au SQE. Une telle entrée est appelée une entrée de file d'attente d'achèvement (CQE) et contient des champs tels qu'un code d'erreur et une valeur de résultat. L'application de l'espace utilisateur peut interroger le CQ pour de nouvelles entrées afin de déterminer si les SQE envoyés ont terminé le traitement et quel a été leur résultat.

Il est mentionné que il existe des scénarios dans lesquels il est facile de remplacer un objet sur la marche. Mais il y a deux limites :

  • LT' doit être assigné et initialisé dans une fenêtre de course. C'est-à-dire après la libération du LT mais avant d'atteindre un point du LT qui n'est plus accessible.
  • LT' ne peut être qu'un autre objet struct io_kiocb. En raison de l'isolation du tas, où les objets du tas sont séparés en fonction de leur type, il est trop difficile de les réaffecter en tant que type d'objet différent dans la fenêtre de course.

Des chercheurs ont préparé un exploit fonctionnel qui ne nécessite pas l'inclusion d'espaces de noms d'identifiant d'utilisateur (espaces de noms d'utilisateur) pour son fonctionnement et peut fournir un accès root à l'hôte lorsqu'un utilisateur non privilégié lance l'exploit dans un conteneur isolé.

Notre exploit cible la version 5.10.90 du noyau, la version que Google exécutait à distance à l'époque. Nous avons dû ajuster notre exploit aux spécifications particulières du serveur (4 cœurs Skylake Xeon à 2.80 GHz, 16 Go de RAM), mais avec quelques ajustements, toute machine exécutant un noyau vulnérable devrait être exploitable.

L'exploit fonctionne également dans l'environnement nsjail isolé sur la distribution Google COS (Container Optimized OS) basée sur Chromium OS et utilisé sur Google Cloud Platform sur les machines virtuelles Compute Engine. L'exploit est conçu pour fonctionner avec les branches du noyau de 5.10 à 5.12. Enfin, il convient de mentionner que le problème a été résolu en avril dans les mises à jour 5.10.111, 5.15.34 et 5.17.3.

Enfin, si vous souhaitez en savoir plus sur la vulnérabilité, vous pouvez consulter la publication faite dans le lien suivant.


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.