Project Zero heeft details vrijgegeven van een ernstige inbreuk op de beveiliging op GitHub en dat melden ze de fout is van invloed op actieworkflowopdrachten van GitHub en wordt beschreven als zeer ernstig. (Deze bug is in juli ontdekt, maar op basis van de standaardtermijn van 90 dagen zijn de details pas nu vrijgegeven.)
Deze fout werd een van de weinige kwetsbaarheden die niet werd verholpen correct voordat de standaardperiode van 90 dagen die door Google Project Zero is toegekend, is verstreken.
Volgens Felix Wilhelm (die het ontdekte), Project Zero-teamlid, heeft de fout invloed op de GitHub Actions-functie, een tool om het werk van ontwikkelaars te automatiseren. Dit komt doordat de werkstroomopdrachten van Actions "kwetsbaar zijn voor injectie-aanvallen":
“Acties Github ondersteunt een functie genaamd workflow-opdrachten als communicatiekanaal tussen de Action Broker en de uitgevoerde actie. Workflow-opdrachten zijn geïmplementeerd in / src / Runner.Worker / ActionCommandManager.cs en het werkt door STDOUT van alle uitgevoerde acties te parseren door te zoeken naar een van de twee opdrachtmarkeringen.
Zeg dat maar het grote probleem met deze functie is dat deze erg kwetsbaar is voor injectie-aanvallen. Omdat het uitvoeringsproces elke rij die in STDOUT wordt afgedrukt, scant op workflow-opdrachten, is elke GitHub-actie die niet-vertrouwde inhoud bevat als onderdeel van de uitvoering ervan kwetsbaar.
In de meeste gevallen leidt de mogelijkheid om willekeurige omgevingsvariabelen in te stellen tot uitvoering van externe code zodra een andere workflow wordt uitgevoerd. Ik heb wat tijd besteed aan het bekijken van populaire GitHub-repositories en bijna elk project dat enigszins complexe GitHub-acties gebruikt, is kwetsbaar voor dit soort bugs.
Posteriormente, gaf enkele voorbeelden van hoe de bug kon worden misbruikt en stelde ook een oplossing voor:
“Ik weet echt niet zeker wat de beste manier is om het te repareren. Ik denk dat de manier waarop workflow-opdrachten worden geïmplementeerd fundamenteel onveilig is. Het afschrijven van de v1-opdrachtsyntaxis en versterken vanet-env met een toegestane lijst zou waarschijnlijk werken tegen directe RCE-vectoren.
“Maar zelfs de mogelijkheid om de 'normale' omgevingsvariabelen die in latere stappen worden gebruikt, te overschrijven, is waarschijnlijk voldoende om de meer complexe acties te exploiteren. Evenmin heb ik de beveiligingsimpact van de andere controles in de werkruimte geanalyseerd.
Bovendien, vermeld dat dit een goede langetermijnoplossing is het zou zijn om de workflow-commando's naar een apart kanaal te verplaatsen (bijv. een nieuwe bestandsdescriptor) om parsing door STDOUT te vermijden, maar dit zal veel bestaande actiecode breken.
Wat GitHub betreft, de ontwikkelaars ervan plaatsten op 1 oktober een advies en verwierpen de kwetsbare commando's, maar voerden aan dat wat Wilhelm ontdekte in feite een "gematigd beveiligingsprobleem" was. GitHub heeft de bug-ID CVE-2020-15228 toegewezen:
“Er is een gematigd beveiligingsprobleem vastgesteld in de GitHub Actions-runtime die de injectie van paden en omgevingsvariabelen in workflows mogelijk maakt die niet-vertrouwde gegevens in STDOUT registreren. Dit kan leiden tot de introductie of wijziging van omgevingsvariabelen zonder de bedoeling van de workflowauteur.
“Om ons te helpen dit probleem op te lossen en u in staat te stellen dynamisch omgevingsvariabelen in te stellen, hebben we een nieuwe set bestanden geïntroduceerd om omgevings- en padupdates in workflows af te handelen.
“Als u door uzelf gehoste brokers gebruikt, zorg er dan voor dat deze zijn bijgewerkt naar versie 2.273.1 of hoger.
Volgens Wilhelm nam Project Zero op 12 oktober contact op met GitHub en bood hen proactief een venster van 14 dagen aan als GitHub meer tijd wilde hebben om de kwetsbare commando's uit te schakelen. Het aanbod werd natuurlijk geaccepteerd en GitHub hoopte na 19 oktober de kwetsbare commando's uit te schakelen. Project Zero stelde vervolgens de nieuwe openbaarmakingsdatum in op 2 november.
bron: https://bugs.chromium.org