Project Zero frigav detaljer om et alvorligt sikkerhedsbrud på GitHub og de rapporterer det fejlen påvirker kommandoer til arbejdsprocesser fra GitHub og beskrives som høj sværhedsgrad. (Denne fejl blev opdaget i juli, men baseret på den almindelige 90-dages offentliggørelsesperiode er detaljerne kun frigivet nu.)
Denne fejl blev en af de få sårbarheder, der ikke blev løst ordentligt inden den standardperiode på 90 dage, der er tildelt af Google Project Zero, udløb.
Ifølge Felix Wilhelm (der opdagede det), Project Zero-teammedlem, påvirker fejlen GitHub Actions-funktionen, et værktøj til at automatisere udvikleres arbejde. Dette skyldes, at kommandoer for Handlings-workflow er "sårbare over for injektionsangreb":
“Handlinger Github understøtter en funktion kaldet workflow-kommandoer som en kommunikationskanal mellem Action-mægleren og den udførte handling. Workflow-kommandoer implementeres omkring / src / Runner.Worker / ActionCommandManager.cs, og det fungerer ved at analysere STDOUT af alle handlinger, der udføres ved at lede efter en af de to kommandomarkører.
Nævn det det store problem med denne funktion er, at den er meget sårbar over for injektionsangreb. Fordi udførelsesprocessen scanner hver række, der udskrives i STDOUT for workflowkommandoer, er hver GitHub-handling, der indeholder ikke-betroet indhold som en del af dens udførelse, sårbar.
I de fleste tilfælde resulterer muligheden for at indstille vilkårlige miljøvariabler i ekstern kørsel af kode, så snart en anden arbejdsgang kører. Jeg har brugt noget tid på at se på populære GitHub-arkiver, og næsten ethvert projekt, der bruger lidt komplekse GitHub-handlinger, er sårbart over for denne slags fejl.
efterfølgende, gav nogle eksempler på, hvordan fejlen kunne udnyttes og foreslog også en løsning:
”Jeg er virkelig ikke sikker på, hvad der er den bedste måde at løse det på. Jeg tror, at den måde, hvorpå workflowkommandoerne implementeres, er grundlæggende usikker. Forringelse af v1-kommandosyntaks og styrkelse af set-env med en tilladelsesliste vil sandsynligvis arbejde mod direkte RCE-vektorer.
“Selv evnen til at tilsidesætte de 'normale' miljøvariabler, der bruges i senere trin, er sandsynligvis nok til at udnytte de mere komplekse handlinger. Jeg har heller ikke analyseret sikkerhedspåvirkningen af de andre kontroller i arbejdsområdet.
På den anden side, nævner, at en god langsigtet løsning det ville være at flytte arbejdsgangskommandoer til en separat kanal (f.eks. en ny filbeskrivelse) for at undgå parsing af STDOUT, men dette vil bryde en masse eksisterende handlingskode.
Med hensyn til GitHub sendte dens udviklere en rådgivning den 1. oktober og afskrev de sårbare kommandoer, men hævdede, at det, som Wilhelm fandt, faktisk var en "moderat sikkerhedssårbarhed." GitHub tildelte bug-identifikatoren CVE-2020-15228:
“Der er identificeret en moderat sikkerhedssårbarhed i GitHub Actions-runtime, der kan tillade indsprøjtning af stier og miljøvariabler i arbejdsgange, der logger upålidelige data til STDOUT. Dette kan føre til introduktion eller ændring af miljøvariabler uden hensigten med workflowforfatteren.
”For at hjælpe os med at løse dette problem og give dig mulighed for dynamisk at indstille miljøvariabler, har vi introduceret et nyt sæt filer til at håndtere miljø- og stiopdateringer i arbejdsgange.
“Hvis du bruger mæglere, der er selvhostede, skal du sørge for, at de opdateres til version 2.273.1 eller højere.
Ifølge Wilhelm kontaktede Project Zero den 12. oktober GitHub og tilbød dem proaktivt et 14-dages vindue, hvis GitHub ønskede mere tid til at deaktivere de sårbare kommandoer. Selvfølgelig blev tilbudet accepteret, og GitHub håbede at deaktivere de sårbare kommandoer efter 19. oktober. Project Zero indstil derefter den nye offentliggørelsesdato til 2. november.
kilde: https://bugs.chromium.org