Connexion
Abonnez-vous

GitLab corrige deux failles critiques, dont une très simple à exploiter

Simple comme un email

GitLab corrige deux failles critiques, dont une très simple à exploiter

GitLab a corrigé deux failles critiques de sécurité, dont une possédant un score CVSS de 10, le maximum. Elles touchent de nombreuses versions. L'entreprise recommande aux clients de mettre à jour leurs instances aussi rapidement que possible.

Le 15 janvier à 10h48

GitLab, concurrent open source de GitHub, est une plateforme de DevSecOps, avec suivi des bugs et modifications, proposant des fonctions de type CI/CD (intégration continue, livraison continue) et de wiki. Elle a connu notamment un succès renouvelé quand Microsoft a annoncé le rachat de GitHub.

Le service a reçu en fin de semaine dernière deux correctifs conséquents, à destination de deux failles critiques aux notes de sévérité très élevées : 9,6 et surtout 10 pour la seconde. Une note maximale que peu de failles atteignent. On se souvient par exemple de la vulnérabilité béante chez ownCloud en novembre.

Sévérité maximale et exploitation « triviale »

La faille notée 10, estampillée CVE-2023-7028, réside dans le processus de vérification des courriers électroniques quand une réinitialisation du mot de passe est demandée. Exploitée, elle peut faciliter la prise de contrôle d’un compte en envoyant des emails de réinitialisation à des adresses non vérifiées.

« Dans ces versions, tous les mécanismes d'authentification sont concernés. En outre, les utilisateurs qui ont activé l'authentification à deux facteurs sont vulnérables à la réinitialisation du mot de passe, mais pas à la prise de contrôle du compte, car leur deuxième facteur d'authentification est nécessaire pour se connecter », indique GitLab dans son bulletin. GitLab recommande chaudement d'activer l’authentification à deux facteurs si ce n'est pas déjà fait. Voilà qui rejoint notre dernier édito sur le sujet.

La dangerosité de la faille tient aux conséquences de son exploitation, la possibilité de s’en servir à distance et l’extrême facilité à le faire, l’ANSSI la qualifiant de « triviale » (une requête HTTP POST suffit).  GitLab indique ne pas avoir détecté d’exploitation active de cette faille.

Cette dernière concerne de nombreuses versions, pour les éditions Community et Enterprise :

    • 16.1.x antérieures à la 16.1.6

    • 16.2.x antérieures à la 16.2.9

    • 16.3.x antérieures à la 16.3.7

    • 16.4.x antérieures à la 16.4.5

    • 16.5.x antérieures à la 16.5.6

    • 16.6.x antérieures à la 16.6.4

    • 16.7.x antérieures à la 16.7.2

Tous les comptes affectés par l’une de ces versions ont été avertis par email.

Outre l’application des mises à jour, GitLab recommande de vérifier deux éléments. D’une part, le journal d’activité « gitlab-rails/production_json.log » pour y chercher d’éventuelles traces de requêtes HTTP sur le chemin « /user/password », avec plusieurs adresses. D’autre part, dans le journal « gitlab-rails/audit_json.log », de possibles identifiants correspondant à « PasswordsController#create » avec des « target_details » contenant plusieurs adresses.

D'autres failles corrigées, dont une critique

L’autre faille, nommée CVE-2023-5356, dispose d’un score CVSS de 9,6, la rendant presque aussi critique. Exploitée, elle peut permettre à un attaquant d’abuser des intégrations Slack et Mattermost pour exécuter des commandes (via « / ») en se faisant passer pour un autre utilisateur.

Toutes les versions antérieures aux 16.5.6, 16.6.4 et 16.7.2 sont touchées. Là encore, il est recommandé de mettre à jour les instances concernées aussi rapidement que possible.

À noter que deux correctifs supplémentaires sont proposés. Le premier est pour la faille CVE-2023-4812 (CVSS 7,6), qui peut permettre de contourner l’approbation CODEOWNERS. Le second colmate la brèche CVE-2023-6955 (CVSS 6,6), qui peut permettre la création d’un espace de travail dans un groupe associé avec l’agent utilisateur d’un autre groupe.

Commentaires (8)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Merci pour cette info ! J'ai demandé une maj en urgence au boulot pour notre gilab !
votre avatar
Nous ça a été fait ce jour sur tous nos serveurs gitlabs. :)
votre avatar
J'ai fait la màj de mon serveur perso à l'arrache depuis mon tél sur ma pause déj...

et je me suis demandé "pourquoi je garde ce service, les potes qui étaient dessus sont finalement allés chez github malgré leurs bonnes intentions ?"
votre avatar
Garder le contrôle de ses données? :D
Sinon en perso c'est clair que la question se pose vraiment, surtout sur des projets opensources.
votre avatar
Le contrôle de ses données en effet, et aussi les clauses à la con qui sont apparues dans les CGU de github au fil du temps...
votre avatar
Si tu ne veux plus maintenir un GitLab, tu as éventuellement Codeberg qui est un service communautaire basé sur Forgejo, l'énième fork the Gog/Gitea.
votre avatar
GitLab indique ne pas avoir détecté d’exploitation active de cette faille.

Ça n'a pas duré longtemps. Serveur patché vendredi matin, les premières tentatives ont eu lieu en milieu d'après-midi et depuis ça n'arrête pas...
votre avatar
Un peu comme Log4Shell où une fois la faille révélée, les logs des serveurs étaient bourrés de tentatives.

Sur mon site perso c'est fou le nombre de personnes intéressées par des .env ou autre dossiers wp-admin. :D

GitLab corrige deux failles critiques, dont une très simple à exploiter

  • Sévérité maximale et exploitation « triviale »

  • D’autres failles corrigées, dont une critique

Fermer