Project Zero ga ut detaljer om et alvorlig sikkerhetsbrudd på GitHub og de rapporterer om det feilen påvirker arbeidsflytkommandoer for handling fra GitHub og er beskrevet som høy alvorlighetsgrad. (Denne feilen ble oppdaget i juli, men under den vanlige opplysningsperioden på 90 dager har detaljene bare blitt utgitt nå.)
Denne feilen ble en av få sårbarheter som ikke ble løst riktig før standard 90-dagers tidsramme gitt av Google Project Zero utløp.
I følge Felix Wilhelm (som oppdaget det), Project Zero-teammedlemmet, påvirker feilen handlingsfunksjonen til GitHub, et verktøy for å automatisere utvikleres arbeid. Dette er fordi kommandoer for arbeidsflyt for handlinger er "sårbare for injeksjonsangrep":
“Handlinger Github støtter en funksjon som kalles arbeidsflytkommandoer som en kommunikasjonskanal mellom Action runner og den utførte handlingen. Arbeidsflytekommandoer er implementert i / src / Runner.Worker / ActionCommandManager.cs, og det fungerer ved å analysere STDOUT av alle handlinger som utføres ved å lete etter en av de to kommandomarkørene.
Nevn det det store problemet med denne funksjonen er at den er veldig sårbar for injeksjonsangrep. Fordi kjøringsprosessen skanner hver rad som skrives ut i STDOUT for arbeidsflytekommandoer, er hver GitHub-handling som inneholder ikke-klarert innhold som en del av kjøringen, sårbar.
I de fleste tilfeller resulterer evnen til å angi vilkårlige miljøvariabler i ekstern kjøring av kode så snart en annen arbeidsflyt kjører. Jeg har brukt litt tid på å se på populære GitHub-arkiver, og nesten alle prosjekter som bruker litt komplekse GitHub-handlinger er sårbare for denne typen feil.
senere, ga noen eksempler på hvordan feilen kunne utnyttes og foreslo også en løsning:
“Jeg er virkelig ikke sikker på hva som er den beste måten å fikse det på. Jeg tror måten arbeidsflytkommandoene er implementert på er fundamentalt usikker. Å spre v1-kommandosyntaks og styrkeet-env med en tillatelsesliste vil trolig virke mot direkte RCE-vektorer.
"Selv evnen til å overstyre de 'normale' miljøvariablene som brukes i senere trinn, er imidlertid nok til å utnytte de mer komplekse handlingene. Jeg har heller ikke analysert sikkerhetspåvirkningen til de andre kontrollene i arbeidsområdet.
På den annen side, nevner at en god langsiktig løsning Det ville være å flytte arbeidsflytekommandoer til en egen kanal (f.eks. En ny filbeskrivelse) for å unngå parsing av STDOUT, men dette vil bryte mye av eksisterende handlingskode.
Når det gjelder GitHub, la utviklerne ut en veiledning 1. oktober og avskrev de sårbare kommandoene, men hevdet at det Wilhelm fant faktisk var en "moderat sikkerhetssårbarhet." GitHub tilordnet feilidentifikatoren CVE-2020-15228:
“Det er identifisert et moderat sikkerhetsproblem i løpetiden for GitHub Actions som kan tillate injeksjon av baner og miljøvariabler i arbeidsflyter som logger upålitelige data til STDOUT. Dette kan føre til innføring eller modifisering av miljøvariabler uten intensjonen til arbeidsflytforfatteren.
“For å hjelpe oss med å løse dette problemet og la deg dynamisk sette miljøvariabler, har vi introdusert et nytt sett med filer for å håndtere miljø- og baneoppdateringer i arbeidsflyter.
“Hvis du bruker meglere som er vertskap, må du sørge for at de er oppdatert til versjon 2.273.1 eller nyere.
I følge Wilhelm kontaktet Project Zero 12. oktober GitHub og tilbød dem proaktivt et 14-dagers vindu hvis GitHub ønsket mer tid til å deaktivere de sårbare kommandoene. Selvfølgelig ble tilbudet akseptert, og GitHub håpet å deaktivere de sårbare kommandoene etter 19. oktober. Project Zero satte deretter den nye avsløringsdatoen for 2. november.
Fuente: https://bugs.chromium.org