Project Zero a publicat detalii despre o încălcare gravă a securității pe GitHub și ei raportează că eroarea afectează comenzile fluxului de lucru de acțiune de la GitHub și este descris ca fiind de severitate ridicată. (Această eroare a fost descoperită în iulie, dar pe baza perioadei standard de divulgare de 90 de zile, detaliile au fost publicate doar acum.)
Acest defect a devenit una dintre puținele vulnerabilități care nu au fost remediate înainte de expirarea termenului standard de 90 de zile acordat de Google Project Zero.
Potrivit lui Felix Wilhelm (cine l-a descoperit), membru al echipei Project Zero, defectul afectează funcția de acțiuni a GitHub, un instrument de automatizare a activității dezvoltatorilor. Acest lucru se datorează faptului că comenzile fluxului de lucru Actions sunt „vulnerabile la atacurile de injecție”:
„Acțiuni Github acceptă o caracteristică numită comenzi de flux de lucru ca un canal de comunicare între brokerul de acțiune și acțiunea executată. Comenzile fluxului de lucru sunt implementate în / src / Runner.Worker / ActionCommandManager.cs și funcționează prin analizarea STDOUT a tuturor acțiunilor efectuate prin căutarea unuia dintre cei doi markeri de comandă.
Menționează că marea problemă cu această caracteristică este că este foarte vulnerabilă la atacurile de injecție. Deoarece procesul de execuție scanează fiecare rând tipărit în STDOUT pentru comenzile fluxului de lucru, fiecare acțiune GitHub care conține conținut neatins ca parte a execuției sale este vulnerabilă.
În majoritatea cazurilor, capacitatea de a seta variabile de mediu arbitrare are ca rezultat executarea codului la distanță imediat ce se execută un alt flux de lucru. Am petrecut ceva timp uitându-mă la depozitele populare GitHub și aproape orice proiect care folosește acțiuni GitHub ușor complexe este vulnerabil la acest tip de eroare.
ulterior, a dat câteva exemple despre modul în care bug-ul ar putea fi exploatat și, de asemenea, a sugerat o soluție:
„Chiar nu sunt sigur care este cel mai bun mod de a remedia problema. Cred că modul în care sunt implementate comenzile fluxului de lucru este fundamental nesigur. Deprecierea sintaxei comenzii v1 și consolidarea-env cu o listă de permisiuni ar funcționa probabil împotriva vectorilor RCE direcți.
„Cu toate acestea, chiar și capacitatea de a suprascrie variabilele de mediu„ normale ”utilizate în etapele ulterioare este probabil suficientă pentru a exploata acțiunile mai complexe. Nici nu am analizat impactul asupra securității celorlalte controale din spațiul de lucru.
Pe de altă parte, menționează că o soluție bună pe termen lung Ar fi să mutați comenzile fluxului de lucru pe un canal separat (de exemplu, un nou descriptor de fișier) pentru a evita analizarea prin STDOUT, dar acest lucru va sparge o mulțime de cod de acțiune existent.
În ceea ce privește GitHub, dezvoltatorii săi au postat un aviz pe 1 octombrie și au respins comenzile vulnerabile, dar au susținut că ceea ce a găsit Wilhelm este de fapt o „vulnerabilitate moderată de securitate”. GitHub a atribuit identificatorul de erori CVE-2020-15228:
„O vulnerabilitate de securitate moderată a fost identificată în runtime-ul GitHub Actions, care poate permite injectarea de căi și variabile de mediu în fluxurile de lucru care înregistrează date neacredibile în STDOUT. Acest lucru poate duce la introducerea sau modificarea variabilelor de mediu fără intenția autorului fluxului de lucru.
„Pentru a ne ajuta să rezolvăm această problemă și pentru a vă permite să setați dinamic variabile de mediu, am introdus un nou set de fișiere pentru a gestiona actualizările de mediu și de cale în fluxurile de lucru.
„Dacă utilizați brokeri auto-găzduiți, asigurați-vă că sunt actualizați la versiunea 2.273.1 sau mai recentă.
Potrivit lui Wilhelm, pe 12 octombrie, Project Zero a contactat GitHub și le-a oferit în mod proactiv o fereastră de 14 zile dacă GitHub dorea mai mult timp pentru a dezactiva comenzile vulnerabile. Desigur, oferta a fost acceptată și GitHub spera să dezactiveze comenzile vulnerabile după 19 octombrie. Proiectul Zero a stabilit apoi noua dată a dezvăluirii pentru 2 noiembrie.
Fuente: https://bugs.chromium.org