GitLab waarschuwt voor bug waarmee aanvaller pipelines als user kon uitvoeren

GitLab waarschuwt gebruikers voor een ernstige kwetsbaarheid waarmee het mogelijk is voor aanvallers om pipelines uit te voeren alsof ze gebruikers zijn. Zo kon er onder andere data worden ontvreemd of code worden aangepast in repository's.

GitLab heeft de kwetsbaarheid gerepareerd in versies 16.3.4 en 16.2.7 van zowel Community Edition als Enterprise Edition. In die versies is slechts een bugfix doorgevoerd. Dat is een ernstige bug die tussen alle versies van 13.12 tot 16.2.7 en alle versies van 16.3 tot 16.3.4 zit.

De nieuwe kwetsbaarheid heeft te maken met een eerdere bug in GitLab, CVE-2023-3932. Die werd eerder in augustus in versie 16.2.3 en 13.11 al gerepareerd. Die bug maakte het mogelijk voor een aanvaller om een pipeline uit te voeren met dezelfde rechten als een willekeurige gebruiker. Zo'n pipeline is een commando waarin staat beschreven wat GitLab moet doen. Omdat het mogelijk was iedere soort pipeline uit te voeren, kon een aanvaller in theorie veel doen. Zo was het mogelijk data of code te exfiltreren met daarin ook mogelijke secrets, of er kon juist code met malware aan een repo worden toegevoegd. De nieuwe bug is daar een omzeiling van. Die wordt getrackt als CVE-2023-4998 en krijgt een CVSS-score van 9.6.

Details over de bug zijn nog niet publiek. De bug werd ontdekt door onderzoeker Johan Carlsson, die dat via bugbountyprogramma HackerOne aandroeg en daar 29.000 dollar voor ontving. Details op HackerOne zijn op het moment nog niet openbaar. Carlsson vond de eerdere bug ook al, maar wist daar nu een omzeiling voor te vinden.

Reacties (15)

[jaenster]

Dus als je een prive gitlab instance hebt, als zeg bedrijf, en je hebt een medewerker die niet de volledige toegang heeft? Dan kan die op een knopje drukken (via 100 omwegen) om een ci/cd uit te voeren, en zo iets live zetten ofzo?

Dan moet je toch al een account hebben. Sure, het is een escalatie van access, maar je moet doorgaans toch al een programmeur zijn bij een bedrijf om iets te kunnen. Dan kan je wel ergere dingen dan een pipeline draaien lijkt me

[Yggdrasil]

Ja, maar veel aanvallen vinden via via plaats. Als een externe aanvaller bijv. via social engineering toegang krijgt tot een account van een gewone developer dan kan die met deze bug mogelijk alle broncode lezen, bewerken en zelfs nieuwe builds maken en deployen. Pipelines hebben vaak toegang tot keys en wachtwoorden om builds te kunnen maken, etc. Dit risico is echt niet denkbeeldig.

[supersnathan94]

Wie heeft het over private gitlab instances? Kan ook in de cloud.

Daarnaast zijn dit soort supply chain attacks juist heel erg heftig omdat het lang kan duren voor de gevolgen duidelijk zijn. Ondertussen kun je miljoenen mensen hebben geïnfecteerd met ransomware of cryptojackers.

[jaenster]

Ik neem eventjes aan dat je niet een ci/cd kan aanmaken, alleen een kan starten. Dus, hoe ga je iets hacken door, een random pipeline te kunnen runnen? Bedoel, dit is iets wat niet de bedoeling is, maar ik zie niet heel snel een manier van misbruik in. Dit is geen "stop de persen" we gaan het nu fixen lek. Sure, update snel, maar niet zet het bedrijf stil, en update.

[supersnathan94]

Als je een pipeline kunt runnen is er ook een mogelijkheid om een pipeline te retryen. Ik weet niet of het bij Gitlab ook mogelijk is om een pipeline bij een retry aan te passen zoals dat bij Jenkins kan, maar dan kun je wel degelijk een aangepaste run doen en scripting injecteren die bijvoorbeeld secrets post in logs of via curl naar een api.

[Ventieldopje]

Let wel dat dit bovenop de bovenop alle updates is die als "kritiek" aangemerkt worden steeds. Poos geleden maar opgehouden met een GitLab instantie zelf te hosten, het was iedere week wel raak met een kritieke update.

[Heidistein]

Tjah... dan kan je ook wel ophouden met Windows... Is ook elke maand raak. Linux ook maar weg, ook elke week wel iets. Chrome is ook steeds lek, evenals Firefox. Potje potje, notepad.exe was zelfs de sjaak, net als vim. Blijkt dat Emacs en FreeBSD ook steeds allemaal lekken hebben. Nee! Ik zie dat Juniper, Microtik en Cisco ook aan de lopende band updated hebben, internet ook maar de deur uit.
Ook de auto maar de deur uit, had laatst ook iets te updaten.

[miitjohn]

Als je de gitlab ontwikkelingen wat volgt dan merk je (via de gitlab issues zelf) dat het echt wel een kluwen is van developers, PR´s, features op features enz. Op zich prima, dat houdt het product levend en zo wordt ingespeeld op wat users, ontwikkelaars willen. Maar ik stel mij toch de vraag hoe het met de QA zit en dan vooral richting security. Als je de security related bugs wat opvolgt die er zo uit gitlab komen dan krab je toch wel eens in het haar. Met devsecops kan je een hele hoop in gitlab steken, er kunnen ook secrets inzitten intended of unintended al dan niet bij source code repositories.

De dingen die je in gitlab steekt liggen aan de bron van software die je later verspreid of zal gebruikt worden, en als je ci/cd doet ga je ook de mogelijkheid hebben om met andere systemen te connecteren. Dus ik zou dit toch niet zomaar over dezelfde kam scheren als een bug in windows of dan maar zeggen dat je het hele internet best afzet.

Nu, op gitlab.com zal het misschien wel meevallen omdat ze ook snel zijn met patchen en er zijn 100k+ repo´s, je moet al pech hebben dat men net op jou repo´s of groups zit. Als je echter zelf een gitlab host en die is Internet ontsloten, zou ik toch sterk adviseren die altijd af te schermen. Hetzij met een vpn, allowlists, capturing portal, ... een layer of defense die je voor gitlab plaatst, nog voor je op de aanmeld pagina kan landen. Dat is gewoon goed beheer en is in geval van gitlab in veel gevallen ook geen issue daar het toch een soort grijze zone applicatie is: het is vooral technische gebruikers, niet voor anonieme internet gebruikers of andere

[Reactie gewijzigd door miitjohn op 23 juli 2024 16:20]

[jaapzb]

Gitlab is heel erg open in hoe hun bedrijf werkt en wat de processen zijn (moet ook wel want alles is remote)

Dus al die vragen zal je waarschijnlijk wel antwoorden voor vinden in het gitlab handbook, misschien een mooie plek om te beginnen: https://handbook.gitlab.com/handbook/security/

[d3burt]

Yup, het is juist die openheid die mij zo aanspreekt. De time-to-fix bij Gitlab is super kort.

Bovendien zou ik hopen dat iedereen die iets Gitlab achtigs wil draaien
(a) een risicoanalyse maakt
(b) die risico's kleiner maakt met met maatregelen.
Voor de meeste mensen is wat ze in Gitlab bewaren namelijk van grote waarde.

In mijn geval draai ik Gitlab on-premise ("achter de firewall"), en is mijn instance alleen via een VPN te bereiken. Als ik Gitlab in een eigen cloud instance zou draaien zou ik het alsnog zo inrichten dat het alleen via een VPN benaderd kan worden. Het is geen absolute garantie, maar verkleint het aanvalsoppervlak enorm.

Bovendien is het niet moeilijk het zo in te richten dat iedere dag alle OS updates en alle Gitlab updates geïnstalleerd worden. Als er zo'n alert als deze uitkomt hoef ik alleen maar te kijken of de updates goed gewerkt hebben. Nog nooit downtime gehad met Gitlab, en als je ziet hoeveel bewegende delen er onder de motorkap zijn is dat een enorme prestatie.

[syl765]

Er zit wel een verschil in het wekelijks moeten patchen van 1 stuk software of je OS. En persoonlijk vind ik het updaten van gitlab nu niet het meest leuke werk. Best veel zaken die verweven zijn en op een eigen manier aan elkaar geknoopt waardoor het niet heel solide oogt en aan voelt. Maar dat is mijn gevoel.

Gitlab voelt wel een beetje als het oude sendmail waarbij je iedere week al een uurtje in de agenda blokkerde voor de update ronde. Dat waren nog eens tijden...

[jaapzb]

Kijk eens naar wat de "kritieke updates" eigenlijk inhouden. Het zijn vaak problemen die alleen onder hele specifieke omstandigheden daadwerkelijk een risico vormen.

Ik ben blij dat ze er zo open over zijn, er zijn genoeg stukken software die je dagelijks gebruikt waar ook kritieke lekken in zitten die of niet, of stilletjes gefixt worden.

[faim]

Niet elk bedrijf een zelf hosted instance draaien natuurlijk.

[Bioman]

Je hebt wel een account nodig inderdaad. Echter werkte het ook op gitlab.com ook en daar kan uiteraard iedereen een account aanmaken. Enige wat je als aanvaller hoefde te weten was een username en een geldige repositorynaam om bijvoorbeeld de broncode te kunnen achterhalen.

Gezien deze nieuwe exploit een omzeiling is van de vorige fix zal het reproductiepad uit deze bug-report aardig inzicht geven in de werking van de huige bug.

Edit: Gitlab.com is inmiddels uiteraard al gefixt!

[Reactie gewijzigd door Bioman op 23 juli 2024 16:20]

[Tubby]

Gitlab SaaS (hosted) geeft bij mij 16.4 aan. Als ze een beetje hun version scheme volgen zou het daarin gefixed moeten zijn.

Daarnaast, geen gekke builds gezien en automatisch deployen is voor mij nog niet rendabel.

Je kunt de versie zien bovenaan de help page; https://gitlab.com/help/

[Reactie gewijzigd door Tubby op 23 juli 2024 16:20]