Beveiligingsonderzoekers op de diepte publiceerden op 24 juli voor het eerst werkende exploitcode voor een GitLab-fout die GitLab zes weken eerder, op 10 juni, had gepatcht. Het voert opdrachten uit als git op elk zelfbeheerd 18.11.3 server die de update niet heeft uitgevoerd.
Elke geverifieerde gebruiker die naar een project kan pushen, kan het uitvoeren. De aanvaller commit een vervaardigd Jupyter-notebook en opent de commit-diff, die een heap-pointer lekt. Genoeg daarvan en een geautomatiseerde sonde kunnen de bibliotheken in het geheugen lokaliseren. Nog twee notebooks vuren vervolgens de lading af. Geen beheerdersrechten, geen CI- of runner-toegang, geen slachtofferinteractie, geen toegang tot het project van iemand anders.
GitLab heeft de oplossing niet als beveiligingsoplossing ingediend. Een recensie door The Hacker News vond de Oj 3.17.3 bump vermeld onder bugfixes in de patchrelease van 10 juni, niet in de tabel met beveiligingsoplossingen. Er is geen CVE, geen CVSS-score en geen sprake van de notebook-diff-keten. Operators die deze vrijgave aan de beveiligingstafel toevertrouwden, hadden geen reden om deze als urgent te beschouwen.
Twee bugs voor geheugencorruptie in Oj, een Ruby JSON-parser die grotendeels in native C is geïmplementeerd, zorgen ervoor dat de keten werkt. depthfirst zegt dat het systeem ze autonoom heeft gemarkeerd, en dat onderzoekers ze met de hand hebben geketend.
GitLab’s notebook-renderer, een juweeltje in de boom genaamd ipynbdiffwordt door de repository gecontroleerd .ipynb JSON naar Oj::Parser.usual.parse in een langlevende Puma-werknemer, zodat door de aanvaller bestuurde bytes het handmatig beheerde C-geheugen van Oj binnen het applicatieproces bereiken.
Eén bug schrijft voorbij een vaste neststapel van 1.024 bytes totdat deze de parser controleert start terugbellen. De andere kapt een objectsleutel van 65.565 bytes af tot 29 in een ondertekend 16-bits veld en retourneert een live heap-pointer, die GitLab in de diff weergeeft. Het lek lokaliseert libc en de schrijfopdracht verwijst naar de callback system().
| Onderdeel | Aangetast | Eerst opgelost |
|---|---|---|
| GitLab CE/EE | 15.2.0 tot 18.10.7 | 18.10.8 |
| GitLab CE/EE | 18.11.0 tot 18.11.4 | 18.11.5 |
| GitLab CE/EE | 19.0.0 tot 19.0.1 | 19.0.2 |
| Oj juweeltje | 3.13.0 tot 3.17.1 | 3.17.3 |
Alle niveaus zijn getroffen, CE en EE, Gratis tot en met Ultimate. Ruby zelf niet. Oj 3.17.2 had andere oplossingen uit dezelfde recensie, maar niet deze twee.
Upgrade naar 18.10.8, 18.11.5of 19.0.2. Noch GitLab, noch depthfirst biedt een oplossing voor iedereen die dat niet kan.
De valkuil is Helm en Operator: controleer de GitLab-versie in de Webservice-image waarop Puma draait, niet de grafiek- of Operator-versie. Alles op 15.2 tot en met 18.9 krijgt geen backport, omdat die regels buiten de door GitLab bewaakte patchtreinen vallen, dus die installaties moeten in plaats daarvan naar een ondersteunde release worden verplaatst.
Commando’s worden uitgevoerd als githet account achter Puma. Hoe ver dat gaat, hangt af van hoe de installatie is geïsoleerd. Binnen handbereik: broncode, Rails-geheimen, servicereferenties, CI/CD-gegevens en interne services waarmee de applicatie kan communiceren.
De publieke exploit is gebouwd voor GitLab 18.11.3 op x86-64. Gadget-offsets, registerstatus en jemalloc-gedrag kwamen allemaal voort uit dat beeld, en een herstelde bibliotheekbasis blijft slechts bestaan totdat de Puma-master opnieuw opstart, dus dit is geen drop-in tegen een willekeurig doelwit.
De Oj-bugs zijn algemeen; Het porten van de exploit is echt werk. depthfirst gemeten vijf tot tien minuten voor het zoeken naar geheugen bij een nieuwe installatie met twee werknemers en projecten van één tot twee uur bij langer lopende installaties. Het artikel bevat de volledige keten.
depthfirst rapporteerde de Oj-bugs op 21 mei, de onderhouder voegde de oplossingen samen op 27 mei, en Oj 3.17.3 verscheept op 4 juni. De GitLab-keten ging op 5 juni naar GitLab, werd op 8 juni bevestigd en op 10 juni gepatcht. depthfirst zegt dat het zich niet bewust is van exploitatie in het wild, en dat GitLab de RCE onafhankelijk heeft gereproduceerd. De bredere Oj-beoordeling leverde nog negen CVE-adviezen op, waarvan geen enkele in deze keten.
The Hacker News heeft GitLab gevraagd waarom de oplossing niet als een beveiligingsprobleem werd geclassificeerd en of er een CVE zal worden toegewezen, en vroeg eerst naar de overdraagbaarheid van exploits. Reacties zijn in behandeling.
