GitLab dicht kritieke lekken die aanvallers authenticatie laten omzeilen

GitLab heeft patches uitgebracht voor twee kritiek lekken, waarmee authenticatie omzeild kan worden. De twee kwetsbaarheden treffen de Ruby-SAML-library die GitLab gebruikt voor SAML's single sign-onauthenticatie.

SAML is een open standaard die gebruikt wordt om authenticatie- en autorisatiegegevens uit te wisselen tussen partijen, om bijvoorbeeld single sign-on mogelijk te maken. De twee kwetsbaarheden, CVE-2025-25291 en CVE-2025-25292, kunnen ervoor zorgen dat aanvallers deze beveiliging kunnen omzeilen. Daarvoor hebben ze wel toegang tot een geldig ondertekend SAML-document van een identiteitsprovider, of idp, nodig, zegt GitLab in een securitybulletin. Als een aanvaller dat heeft, dan kan de aanvaller zich authenticeren als een andere legitieme gebruiker binnen de SAML-idp van deze omgeving.

De twee kwetsbaarheden zijn al verholpen op GitLab.com. Voor GitLab-installaties die door gebruikers zelf beheerd worden, GitLab Community Edition en Enterprise Edition, zijn updates uitgebracht. De problemen zijn verholpen in versies 17.7.7, 17.8.5 en 17.9.2. GitLab adviseert met klem om zo snel mogelijk de nieuwste versie te installeren, om de problemen te verhelpen. Het bedrijf heeft ook mitigerende maatregelen opgenomen in zijn securitybulletin, voor gebruikers die niet direct kunnen updaten.

GitLab verhelpt in de patches ook zeven andere problemen. Het gaat onder meer om een probleem in de GraphQL Ruby-library, CVE-2025-27407. Deze kwetsbaarheid kan aanvallers in specifieke omstandigheden in staat stellen om op afstand eigen code uit te voeren. Daarvoor moet de aanvaller via een geauthenticeerd gebruikersaccount een malafide project versturen via de Direct Transfer-functie. Die functie zit nu nog in een bètastadium en staat standaard uit in self-managed GitLab-instances.

Reacties (17)

[Anonymoussaurus]

De aanvaller moet eerst toegang hebben tot een gekaapt SAML-user account:

Note: This vulnerability requires the attacker to have compromised a valid user account to perform the authentication bypass.

Daarnaast is het zelf ook te mitigeren als je niet wilt/kan updaten:

1. Enable GitLab two-factor authentication for all user accounts on the GitLab self-managed instance (NOTE: Enabling identity provider multi-factor authentication does not mitigate this vulnerability) and
2. Do not allow the SAML two-factor bypass option in GitLab and
3. Require admin approval for automatically created new users (gitlab_rails['omniauth_block_auto_created_users'] = true)

Wat betreft punt 1: je zou sowieso 2FA moeten enforcen bij al je users, dat is natuurlijk altijd goed om te doen.

[Kees]

Wat betreft punt 1: Dat doet dan weer de hele Single Sign On teniet. Je wil niet voor elke service apart nog eens een keer een extra 2fa invullen als je dat net eerder ook al bij de identity provider hebt gedaan.

Enforcen bij de SSO-provider: Ja, maar bij elke individuele applicatie nog een keer enforcen: Nee.

[Anonymoussaurus]

In mijn geval gebeurt dat ook niet, dus idd geen twee keer 2FA invoeren. Credentials van SSO-provider, en 2FA (eenmalig, op basis van IP) via GitLab zelf. Dat gebeurt niet elke keer, maar alleen de eerste keer inloggen bij de desbetreffende service.

[Reactie gewijzigd door Anonymoussaurus op 13 maart 2025 16:14]

[matthijsln]

Een account kapen was niet nodig: een stukje XML ondertekend door de IdP was al genoeg. Zo'n stukje XML is te zien (client side) na inlog met een geldig account, maar zit ook in publieke SAML metadata. Als Entra gebruikt wordt is dit te vinden op https://login.microsoftonline.com/[tenant-id]/federationmetadata/2007-06/federationmetadata.xml, bij andere IdP's is die metadata ook makkelijk te vinden.

[Reactie gewijzigd door matthijsln op 13 maart 2025 16:48]

[DeTeraarist]

Maar is dit nu een gitlab dingetje, of een ruby-saml dingetje? Of wordt ruby-saml door gitlab onderhouden en zijn andere pakketten met ruby-saml ook kwetsbaar?

[Moartn]

https://github.com/SAML-T...e-ov-file#vulnerabilities

Zo te zien wordt dit niet specifiek door Gitlab onderhouden (de maintainer lijkt niet bij Gitlab te werken iig), en andere paketten die deze library gebruiken zijn dus ook kwetsbaar. Uiteraard nog steeds wel afhankelijk of er nog andere mitigerende maatregelen zijn getroffen.

[DeTeraarist]

github.com zei al genoeg
Beetje vreemd dat het hier gebracht wordt alsof het een gitlab ding is terwijl dus gewoon ieder pakket dat ruby-saml gebruikt kwetsbaar is.

[Robtimus]

Wat is er mis met github.com? Veel grote partijen zitten daar ook op. Denk aan OpenJDK, Go(lang), Apache Commons, .NET, TypeScript, etc.

[Moartn]

Er is niks mis met GitHub, maar als ruby-saml een GitLab(-sponsored) package zou zijn, zou hij natuurlijk niet op GitHub gehost worden

[malmeloo]

Er zijn genoeg dingen mis met GitHub, maar DeTeraarist bedoelt denk ik dat het duidelijk geen project van GitLab is als het op GitHub gehost wordt

[DeTeraarist]

Wat de rest al zei.

Maar, uhm... https://github.com/gitlabhq

[Isnowiz]

Het is veel en veel groter. Er zijn heel veel verschillende SAML-libraries geraakt en er zullen de komende tijd nog een hoop patches uit verschillende hoeken komen. Dat deze nu uit de hoge hoed valt is omdat er gelekt is op een publieke mailinglist waardoor er nu patches gerushed worden. Onder intimi is het issue al maanden bekend.

[Mellow Jack]

Wel bizarre bug maar als ik het goed heb zijn de mitigerende maatregelen al onderdeel vd best practices. Zo mooi zijn als de meeste omgeving al zo zijn geconfigureerd

[Reactie gewijzigd door Mellow Jack op 13 maart 2025 15:36]

[matthijsln]

Dit blog legt uit waar de SAML-kwetsbaarheid in de code zit. Grappig dat juist GitHub (concurrent van GitLab) deze fout heeft ontdekt omdat ze mogelijk ook ruby-saml wilden gaan gebruiken in plaats van hun eigen implementatie.

Het probleem is ook wel mede het resultaat van de complexiteit van het op XML-gebaseerde SAML protocol. Een JWT signature is makkelijk te valideren maar in SAML is dit complex door het gebruik van XML met interne verwijzingen naar digests en signatures en het moeten "canonicaliseren". Omdat een Ruby XML bibliotheek het canonicaliseren niet ondersteunde werden er twee XML-parser bibliotheken door elkaar gebruikt, en kon een aanvaller ruby-saml de signature van een stukje extra XML (wat zelfs zonder account te vinden is, want ook uit makkelijk te vinden publieke SAML IdP metadata te halen is) laten verifieren maar een niet-geverifieerde assertion (met een andere gebruikersnaam of lijst met rechten) laten accepteren.

[Reactie gewijzigd door matthijsln op 13 maart 2025 16:49]

[closefuture]

SAML is inderdaad complex. Vroeger bood het ook wel echt wat functionaliteit die OIDC miste. Zoals back-channel single logout. Het kan nog steeds wel meer maar in 99% van de use-cases heb je waarschijnlijk niet perse SAML nodig.

XML parsen ansich is al moeilijk om secure te doen. Dingen zoals de good 'ol billion laughs attack zijn voorbeelden van dat bij het ontwerp van XML er eigenlijk onvoldoende nagedacht is over hoe features misbruikt kunnen worden.

Microsoft is overigens ook ooit de boot in gegaan met hun SAML implementatie (destijds in Azure AD). De SolarWinds hack was volgens mij ook gedeeltelijk mogelijk gemaakt door SAML.

[Isnowiz]

Ze hebben helemaal niks ontdekt bij Github. Het issue is al maanden bekend in besloten kringen en raakt vele SAML-producten en/of hun onderliggende libraries. Dat het deze week ineens de kop opsteekt is omdat er gelekt is op een openbare mailinglist.

De rest van je antwoord klinkt al AI

[GeroldM]

Heb GitLab draaien in een Linux VM. 'sudo apt update && sudo apt upgrade -y' en zo'n 5 minuten later draait de ge-update versie. Daarmee nog nooit een klacht ontvangen van de 15 personen die er gebruik van maken, er draaien 22 repo's op en deze hebben (tot op heden) nog nooit data verloren. Deze draaien al enkele jaren.

Verwacht niet dat deze Gitlab server is aangevallen. Zie daar in elk geval niets van terug in logging of via OpenObserve (gebaseerd op OpenTelemetry). en als dat wel gebeurd zou zijn, dan zal het nooit lang mogelijk zijn geweest, ik update Gitlab zowiezo elke 2 weken. Want dat is de cadence waarmee GitLab security-fixes uitbrengt.