Versiebeheersystemen dichten lek dat uitvoeren van code via url toeliet

Versiebeheersystemen Git, Mercurial en SVN hebben een kwetsbaarheid gedicht waarbij een aanvaller commando's op het systeem van een slachtoffer kon uitvoeren door het een bepaalde ssh-url te laten gebruiken.

Recurity Labs-onderzoeker Joern Schneeweisz beschrijft de kwetsbaarheden met respectievelijk kenmerken CVE-2017-1000117, CVE-2017-1000116 en CVE-2017-9800 op zijn blog. Hij kwam er in eerste instantie in Git LFS achter dat als een ssh-url een hostname bevat die begint met een streepje, dat deze dan onterecht als een optie bij het ssh-commando wordt gezien. Daardoor is het mogelijk om willekeurige commando's uit te voeren in programma's die op het systeem aanwezig zijn, als het slachtoffer overgehaald kan worden de url te gebruiken.

Hij vond deze kwetsbaarheid in mei. Twee maanden later vond hij eenzelfde lek in Git, wat het uitvoeren mogelijk maakte via het git clone-commando. Hierbij stelt hij dat er ook een andere manier is om een commando uit te voeren op het systeem van een slachtoffer. Zo is het mogelijk om een dergelijke url in het gitmodules-bestand van een kwaadaardig project op te nemen, waardoor er een commando uitgevoerd kan worden als een slachtoffer het git clone-commando uitvoert met de optie 'recurse submodules'. Later bleek een soortgelijk lek ook in Subversion en Mercurial te zitten.

Volgens Schneeweisz was Subversion het zwaarst getroffen doordat het mogelijk was een http-url via een redirect te gebruiken om de kwetsbaarheid te misbruiken. Inmiddels zijn de nodige patches uitgebracht. Het is niet meer mogelijk een ssh-hostname met een streepje te beginnen en hetzelfde geldt voor een repository.

Reacties (31)

[Jan-E]

Het was overigens wel een gecoordineerde actie van de Subversion, Mercurial, Git en Gitlab ontwikkelaars. Zie de subversion mailinglist:

https://svn.haxx.se/dev/archive-2017-08/0078.shtml

Voor Windows users, hier heb ik gisterochtend vroeg nieuwe subversion binaries gepubliceerd, inclusief de Apache modules:
https://www.apachelounge.com/viewtopic.php?p=35685#35685

[Reactie gewijzigd door Jan-E op 27 juli 2024 03:23]

[Jewest]

Het eerste bij mij op kwam: git ging toch links waar svn rechts ging?

[kdekker]

Beide zijn gedistribueerde versiebeheersystemen, waar een developer een clone/copy van maakt en met een commit zijn wijzigingen terugstuurt. Het product is inderdaad verder verschillend, maar conceptueel delen ze wel een soortgelijk systeem (in grote lijnen dan).

[Verwijderd]

Subversion is een stuk ouderwetser dan Git, omdat het de hele "gedistribueerd versiebeheer"-boot gemist had.

De korte geschiedenis van Git:

• Git is een kloon van BitKeeper. Git was ontwikkeld omdat BitKeeper nogal een irritant licentiemodel had.
• BitKeeper is een distributiesysteem voor BitSCCS-repositories. BitKeeper lijkt speciaal voor Linuxs gemaakt te zijn.[/url]
• BitSCCS is een van de vele (uitgebreide) varianten op SCCS. Het lijkt vooral als deel van BitKeeper ontwikkeld te zijn.

De korte geschiedenis van Subversion:

• Subversion is een kloon van CVS. Subversion was ontwikkeld omdat er aan CVS best wat features ontbraken.
• Concurrent Versions System (CVS) is oorspronkelijk een front-end voor RCS. CVS was ontwikkeld omdat het handig is om met patches te kunnen werken die méér dan één bestand raken.
• Revision Control System (RCS) is een alternatief op SCCS. RCS slaat vooral patches op een andere manier op, waardoor het een stuk beter presteert.

Git is dus een voortborduursel op een project dat afstand neemt van het gecentraliseerde model dat CVS erop nahield, terwijl Subversion juist meer "CVS, maar wél bruikbaar" probeerde te zijn.

Ter volledigheid: Source Code Control System (SCCS; eerste openbare release in 1977) is het oudste versiebeheersysteem en maakt overigens nog steeds deel uit van POSIX.

[djiwie]

Subversion is een stuk ouderwetser dan Git, omdat het de hele "gedistribueerd versiebeheer"-boot gemist had.

Nou ja, gemist: SVN is gewoon al een stuk ouder dan GIT, en was ten opzichte van CVS een stuk beter, maar het borduurde inderdaad wel voort op het centrale server-model. "De boot missen" suggereert dat ten tijde van ontwikkeling van SVN het distributed versioning al een reëel alternatief was. Dat was niet zo, dat ontstond pas serieus toen Git, Mercuriual et al. populair werden (maar dan hebben we het over 5 jaar later).

Je zou kunnen zeggen dat SVN toe nog een poging had kunnen doen door het hele concept 180 graden om te draaien, maar Git heeft dat gat gewoon prima opgevuld en is nu de facto standaard voor versiebeheer.

[Verwijderd]

Dat was inderdaad een beetje gechargeerd, maar ik denk dat het niet ver van de waarheid ligt. Het was toch écht BitKeeper die gedistribueerde versiebeheer een belangrijke optie maakte.

De eerste openbare release van BitKeeper werd in mei 2000 gepubliceerd, een paar maanden voordat Subversion 1.0 uitkwam. GNU arch (de voorloper van Bazaar), DVCS en Darcs kwamen ook uit voordat Git was bedacht. Voordat Torvalds aan Git begon heeft hij zelfs nóg een ander systeem, Monotone, aangewezen als iets waardevols.

De bovengenoemde andere systemen kwamen min of meer in 2002 en 2003 op. Subversion 1.0 kwam uit in 2004. Ze hadden best om zich heen kunnen kijken en plannen kunnen maken voor 2.0.

[Verwijderd]

Dan vergeet je Mercurial (hg). Die ondersteunde dat wel en leek nog het meest op Git.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 03:23]

[RJG-223]

Beide zijn gedistribueerde versiebeheersystemen

Svn is niet gedistribueerd. Git wel.

Bij git maak je een clone / kopie van de hele versie-database van een project. Jouw kopie is daarna technisch gezien equivalent met het origineel. Een commit is daarna lokaal in jouw eigen database. Een derde kan jouw commit(s) daarna in zijn eigen database opnemen (pull), of jij kunt jouw commit(s) naar een andere database sturen (push). Maar dat hoeft allemaal niet.

Bij svn doe je alleen een checkout van de laatste versie. De rest van de database blijft exclusief op de server staan. Een commit van jouw wijzigingen gaat (en moet) altijd naar die ene server. Als die server down is, dan kun je geen commits doen.

[David Mulder]

Als je een repository cloned dan ga je die code ook waarschijnlijk draaien (ken niemand die eerst handmatig de code lijn voor lijn checked)... dus je moet sowieso het project vertrouwen. Dus ja... goede zaak dat ze dit fixen, want blijft onverwacht gedrag, maar niet bepaald iets waar je je volgens mij druk om moet maken .

[kdekker]

Voor bedrijven die SVN (of 1 v.d. andere genoemde projecten gebruikt), doen ze dat vaak intern, op eigen servers. Daarbij, ssh draait als goed is niet als admin/root. De rechten die je hebt zijn (hopelijk) beperkt. Ik denk dat de impact van dit probleem beperkt is, misschien iets meer relevant voor openbare source repositories.

En volgens mij gaat het helemaal niet over code draaien, maar puur over (in genoemde bron) over het ophalen/clonen van een git repository. De code wordt dan op die server uitgevoerd. Een beetje git beheerder zal de boel wel beveiligd hebben. In het ergste geval kun je dan een rm doen op de sources. Dat is wel ernstig, maar heeft nog steeds niets te maken met 'project vertrouwen' (of ik begrijp de bron verkeerd, maar volgens mij slaat jij de plank mis).

[johnkeates]

Ik denk dat je de bron verkeerd begrijpt. Wat het probleem is, is dat er arbitraire code uitgevoerd kan worden als iemand malafide links injecteert. Het is niet iets wat specifiek op een server of werkstation moet gebeuren, het kan overal.

Dit kan dus ook betekenen dat iemand een reverse shell start en daarna vrij toegang heeft tot je systeem, ook als er een firewall op zit (vaak is dat alleen inbound) en je NAT gebruikt in je netwerk (gezien je zelf de origin bent - daarom heet het een reverse shell). Stel dat je systeem iets als netcat, php, java, ruby, perl, bash, python etc. heeft kan je dit dus al doen.

Dus hoewel het probleem zelf niet zo heel spannend is (het is bijvoorbeeld veel ernstiger dat je zonder tussenkomst van een gebruiker alle Windows PC's met random doelwitten verbinding kan laten maken via SMB:// URL's in webpagina's maar ook in bestanden, mapper, ZIP files enz. waarna je huidige wachtwoord+gebruikersnaam automatisch verzonden worden), is de manier waarop je het zou kunne misbruiken wel vrij breed.

[David Mulder]

Hoe? Wanneer clone je een repository waarvan je de code niet gaat draaien? Want zodra je de code draait heb je dezelfde rechten (of vaak meer) als het ssh commando.

[johnkeates]

Wanneer je een scriptkiddie of tweaker bent die copypasta maakt van random tekst op internet en alles lukraak in z'n shell plakt bijvoorbeeld.

Er zijn ook zat ontwikkelaars die hun eigen tools niet kennen en het niet door hebben wanneer hun favoriete IDE of visuele versie beheer tool op de achtergrond random code van een of andere submodule moet halen en lekker wat binaries draait om dat dat toevallig in de module spec stond.

[David Mulder]

Ik denk niet dat er zelfs ook maar 1 ontwikkelaar te vinden is die al z'n tools tot in die mate kent dat hij met zekerheid kan zeggen dat geen van z'n tools op de achtergrond iets draait waarvan hij niet bewust is. Uiteindelijk komt het gewoon op het menselijk vertrouwen aspect terecht. Vertrouwen of extreme sandboxing (en zelfs dan nog moet je de VM's en/of hardware vertrouwen).

[Verwijderd]

*kuch* Node *kuch*

[Plux]

"Iedereen móet dit gelezen hebben"

Uw manager

[Reactie gewijzigd door Plux op 27 juli 2024 03:23]

[robvanwijk]

Wanneer clone je een repository waarvan je de code niet gaat draaien?

Als je een pull request wilt maken. (Toegegeven, dan draai je de code waarschijnlijk al, maar op een server die je gebruikt voor het ontwikkelen van code kunnen andere gevoelige gegevens staan dan op machines die je gebruikt voor het draaien van code, zodat de exposure toch toeneemt.)

Als je weet dat een bepaald project een handige feature heeft en je wilt kijken hoe ze dat geïmplementeerd hebben.

Ik zie je punt wel hoor; dit lijkt inderdaad niet het ernstigste lek ooit te zijn, maar het is wel degelijk een bug (met in elk geval de theoretische mogelijkheid van een beveiligingslek), dus zodra het gevonden wordt, lijkt het me niet meer dan logisch dat je het oplost. Als een groot onderdeel volledig opnieuw ontworpen en geschreven zou moeten worden om het probleem op te kunnen lossen, dan zou ik het misschien nog wel met je eens zijn; dit is (gevoelsmatig, maar ik heb de diffs niet nagelopen) simpelweg het toevoegen van één extra controle, een paar regels code, dus dan is het beter om het gewoon te fixen.

[kdekker]

Zoals 448191 hieronder ook zegt: het raakt de git client. Het heeft nul relatie met de source code die in de repository staat (ik dacht in eerste instantie dat het juist de git server zou raken, omdat je met de ssh client commando's doorgeeft aan de ssh daemon, de plek waar de git server draait).

[Reactie gewijzigd door kdekker op 27 juli 2024 03:23]

[johnkeates]

De git server is niet de 'server' in de zin van 'apparaat'. De server is een component die zowel lokaal als op een dedicated 'server' kan draaien. Het heeft uiteraard nul relatie met de repo, hoewel je gitmodules ook zou moeten kunnen misbruiken, wat dan wel weer in de repo staat, en je kan de data in de repo misbruiken om daar bijvoorbeeld binaries in te droppen op een systeem waar je in de eerste instantie geen toegang tot had.

Stel dat je remote netcat wil uitvoeren maar er geen netcat op het doelwit staat kan je die dus in de repo stoppen en daarna het lek misbruiken om het te starten.

[448191]

Nee, het gaat erom dat client side een verborgen ProxyCommand kunt uitvoeren. Ja je zou dat weer configureren om de cliënt misbruiken om script op de server te laten uitvoeren, maar zoals je zelf al zegt, die server zit (als het goed is) dicht. Developers, niet git servers, zijn at risk.

[sebastiaan1997]

Het zou niet mogen, daar gaat het om. Niet zozeer of het schadelijk is of niet.

[kdekker]

Dat is wel wat kort door de bocht. Je lost op wat het belangrijkst is. Als je helemaal niets meer te doen is (en dat komt bij een actueel, gebruikt en onderhouden product zelden voor) en je hebt tijd en geld over, dan kom je wellicht toe tot het punt wat jij noemt. Dat is wellicht een utopisch moment.

[mdartu]

Het wordt natuurlijk wat gevaarlijker als je op deze manier code kunt uitvoeren op de server, bijvoorbeeld door zo'n malafide URL te gebruiken i.c.m. "import from git"-functionaliteit, zoals verschillende Git-hosting-partijen die aanbieden. Overigens heeft GitLab daar gisteren al een fix voor uitgebracht en ik neem aan dat andere platformen er ook bovenop zitten.

[kozue]

Niet iedere repository bevat code hoor. Alhoewel dit een veelgebruikte use case is voor versiebeheer, gaat het primair ok het bijhouden van veranderingen tussen bestanden.
Een voorbeeld van niet-uitvoerbare bestanden in versiebeheer is het bericht van gisteren hier over Easylist. Wel git, geen code.

[Perkouw]

Is het nu gewoon stom toeval dat het bij diverse systemen min of meer hetzelfde is gevonden? Ken de tools niet goed genoeg om te weten of deze bijvoorbeeld op elkaar zijn gebaseerd of dat we het hier puur hebben over functioneel ''gelijke'' software.

[sfranken]

Als ik het zo lees en er even over nadenk (icm je reactie) lijkt het me meer op een parser bug, één niveau dieper. Het lijkt me sterk dat GIT, SVN en Mercurial alledrie zo gelijk zijn gebouwd dat ze er alledrie last van hebben.

Echter zijn wonderen de wereld nog niet uit, dus wie weet heeft de bliksem inderdaad drie keer ingeslagen.

[batjes]

De 3 pakketten doen +/- hetzelfde, en zullen voor bepaalde zaken gewoon een vrijwel identieke oplossing ontwikkeld hebben.

[mdartu]

Dat is inderdaad min of meer toeval. De drie genoemde producten delen geen code base, maar ze kunnen alle drie wel ssh gebruiken om data te versturen. De hostname uit de url werd in alle gevallen direct doorgegeven aan ssh, die het als speciaal argument interpreteert als het met een streepje begint.

[kozue]

Is toeval. Ze maken alle 3 blijkbaar dezelfde fout: user input direct doorgeven aan de shell zonder escaping omdat ze er niet bij stil hebben gestaan dat die input kwaadaardig kan zijn. Ik weet zeker dat er nog duizenden stukjes software zijn die dezelfde fout bevatten. Shell code uitvoeren met onveilige user input zit op hetzelfde niveau als sql injecties qua risicofactor en is net zo algemeen.

[cracking cloud]

Zoals The White Cowboy zou zeggen: "Kom op Bles, de stad is gered. Onze taak is gedaan. We hebben nog een lange weg voor de boeg.".

[Reactie gewijzigd door cracking cloud op 27 juli 2024 03:23]

[Ulysses]

Ik las: Kwetsbare code voor URL-toilet ... HAHA iemand anders ook?