Une deuxième vulnérabilité critique a été révélée dans GitLab en moins d'une semaine

Gitlab

Gitlab souffre d'un deuxième problème de sécurité en moins d'une semaine

En moins d'une semaine Les développeurs de Gitlab ont dû se mettre au travail, Eh bien, il y a quelques jours, les mises à jour correctives pour GitLab Collaborative Development Platform 15.3.1, 15.2.3 et 15.1.5 ont été publiées, ce qui a résolu une vulnérabilité critique.

répertorié sous CVE-2022-2884, cette vulnérabilité pourrait permettre à un utilisateur authentifié d'accéder à l'API d'importation GitHub exécuter du code à distance sur un serveur. Aucun détail opérationnel n'a encore été dévoilé. La vulnérabilité a été identifiée par un chercheur en sécurité dans le cadre du programme de primes sur les vulnérabilités de HackerOne.

Pour contourner ce problème, il a été conseillé à l'administrateur de désactiver la fonction d'importation depuis GitHub (dans l'interface Web de GitLab : "Menu" -> "Admin" -> "Paramètres" -> "Général" -> "Contrôles de visibilité et d'accès" -> « Importer des sources » -> désactiver « GitHub »).

Après cela et dans moins d'une semaine gitlab ce Je publie la prochaine série de mises à jour correctives pour leur plate-forme de développement collaboratif : 15.3.2, 15.2.4 et 15.1.6, qui corrige la deuxième vulnérabilité critique.

répertorié sous CVE-2022-2992, cette vulnérabilité permet à un utilisateur authentifié d'exécuter du code à distance sur un serveur. Comme la vulnérabilité CVE-2022-2884 qui a été corrigée il y a une semaine, il existe un nouveau problème d'API pour l'importation de données depuis le service GitHub. La vulnérabilité se manifeste, entre autres, dans les versions 15.3.1, 15.2.3 et 15.1.5, dans lesquelles la première vulnérabilité dans le code d'importation de GitHub a été corrigée.

Aucun détail opérationnel n'a encore été dévoilé. La vulnérabilité a été soumise à GitLab dans le cadre du programme de primes de vulnérabilité de HackerOne, mais contrairement au problème précédent, elle a été identifiée par un autre contributeur.

Pour contourner ce problème, il est recommandé à l'administrateur de désactiver la fonction d'importation depuis GitHub (dans l'interface Web de GitLab : "Menu" -> "Admin" -> "Paramètres" -> "Général" -> "Contrôles de visibilité et d'accès" -> « Importer des sources » -> désactiver « GitHub »).

En outre, les mises à jour proposées corrigent 14 autres vulnérabilités, dont deux sont marqués comme dangereux, dix ont un niveau de gravité moyen et deux sont marqués comme non dangereux.

Sont reconnus dangereux : vulnérabilité CVE-2022-2865, qui vous permet d'ajouter votre propre code JavaScript aux pages affichées aux autres utilisateurs par la manipulation des étiquettes de couleur,

Il était possible d'exploiter une vulnérabilité en configurant la fonctionnalité de couleur d'étiquette qui pourrait conduire à un XSS stocké permettant aux attaquants d'effectuer des actions arbitraires au nom des victimes côté client. 

Une autre des vulnérabilités qui a été résolue avec la nouvelle série de corrections est la CVE-2022-2527, qui permet de remplacer son contenu par le champ description sur la chronologie de l'échelle des incidents). Les vulnérabilités de gravité moyenne sont principalement liées au potentiel de déni de service.

Le manque de validation de la longueur des descriptions d'extraits de code dans GitLab CE/EE affectant toutes les versions antérieures à 15.1.6, toutes les versions de 15.2 antérieures à 15.2.4, toutes les versions de 15.3 antérieures à 15.3.2 permet à un attaquant authentifié de créer un extrait malveillant de grande taille qui, lorsqu'il est demandé avec ou sans authentification, provoque une charge excessive sur le serveur, pouvant conduire à un déni de service.

Parmi les autres vulnérabilités qui ont été résolus :

  • Le registre de paquets n'honore pas entièrement la liste d'adresses IP autorisées du groupe, GitLab ne s'authentifiait pas correctement par rapport à certains registres de packages lorsque les restrictions d'adresse IP étaient configurées, permettant à un attaquant qui possédait déjà un jeton de déploiement valide de l'utiliser à mauvais escient depuis n'importe quel emplacement.
  • Abuser des appels Gitaly.GetTreeEntries conduit à un déni de service, permettant à un utilisateur authentifié et autorisé d'épuiser les ressources du serveur en important un projet malveillant.
  • Requêtes HTTP arbitraires possibles dans .ipynb Notebook avec des balises de formulaire malveillantes, ce qui permet à un attaquant d'émettre des requêtes HTTP arbitraires.
  • Le déni de service d'expression régulière via une entrée spécialement conçue permettait à un attaquant de déclencher une utilisation élevée du processeur via une entrée spécialement conçue ajoutée au champ de message de confirmation.
  • Divulgation d'informations par le biais de références GFM arbitraires représentées dans les événements de la chronologie des incidents
  • Lire le contenu du référentiel via la fonction LivePreview : il était possible pour un utilisateur non autorisé de lire le contenu du référentiel si un membre du projet utilisait un lien spécialement construit.
  • Déni de service via l'API lors de la création d'une branche : une mauvaise gestion des données lors de la création de la branche aurait pu être utilisée pour déclencher une utilisation élevée du processeur.
  • Déni de service via l'aperçu du problème

Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans le lien suivant.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  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.