Project Zero släppte information om ett allvarligt säkerhetsbrott på GitHub och de rapporterar det felet påverkar kommandon för arbetsflödesåtgärder från GitHub och beskrivs som hög svårighetsgrad. (Denna bugg upptäcktes i juli, men baserat på den vanliga 90-dagars avslöjandeperioden har detaljerna bara släppts nu.)
Denna brist blev en av få sårbarheter som inte åtgärdades ordentligt innan den normala 90-dagars tidsram som beviljats av Google Project Zero löpte ut.
Enligt Felix Wilhelm (som upptäckte det), medlem av Project Zero-teamet, påverkar felet GitHubs funktionsfunktion, ett verktyg för att automatisera utvecklarnas arbete. Detta beror på att kommandon för arbetsflödesåtgärder är "sårbara för injektionsattacker":
Åtgärder Github stöder en funktion som kallas arbetsflödeskommandon som en kommunikationskanal mellan åtgärdsmäklaren och den utförda åtgärden. Arbetsflödeskommandon implementeras i / src / Runner.Worker / ActionCommandManager.cs och det fungerar genom att analysera STDOUT av alla åtgärder som utförs genom att leta efter en av de två kommandomarkörerna.
Nämn det det stora problemet med den här funktionen är att den är mycket sårbar för injektionsattacker. Eftersom körningsprocessen skannar varje rad som skrivs ut i STDOUT efter arbetsflödeskommandon, är varje GitHub-åtgärd som innehåller otillförlitligt innehåll som en del av körningen sårbar.
I de flesta fall resulterar möjligheten att ställa in godtyckliga miljövariabler i fjärrkörning av kod så snart ett annat arbetsflöde körs. Jag har spenderat lite tid på att titta på populära GitHub-arkiv och nästan alla projekt som använder lite komplexa GitHub-åtgärder är sårbara för denna typ av fel.
därefter, gav några exempel på hur felet kunde utnyttjas och föreslog också en lösning:
”Jag är verkligen inte säker på vad som är det bästa sättet att fixa det. Jag tror att sättet att kommandona för arbetsflöden implementeras är i grunden osäkert. Försvagning av v1-kommandosyntaxen och förstärkning av en-env med en tillåtningslista skulle troligen fungera mot direkta RCE-vektorer.
”Men även förmågan att åsidosätta de” normala ”miljövariablerna som används i senare steg är nog tillräckligt för att utnyttja de mer komplexa åtgärderna. Inte heller har jag analyserat säkerhetspåverkan av de andra kontrollerna i arbetsytan.
Å andra sidan, nämner att en bra långsiktig lösning det skulle vara att flytta arbetsflödeskommandon till en separat kanal (t.ex. en ny filbeskrivare) för att undvika analysering av STDOUT, men detta kommer att bryta en hel del befintlig åtgärdskod.
När det gäller GitHub publicerade dess utvecklare en rådgivning den 1 oktober och avfärdade de sårbara kommandona, men hävdade att det som Wilhelm fann var i själva verket en "måttlig säkerhetssårbarhet." GitHub tilldelade buggidentifieraren CVE-2020-15228:
”En måttlig säkerhetsproblem har identifierats i GitHub Actions runtime som kan tillåta injicering av banor och miljövariabler i arbetsflöden som loggar opålitliga data till STDOUT. Detta kan leda till introduktion eller modifiering av miljövariabler utan arbetsflödesförfattarens avsikt.
”För att hjälpa oss att lösa detta problem och låta dig dynamiskt ställa in miljövariabler, har vi introducerat en ny uppsättning filer för att hantera miljö- och sökuppdateringar i arbetsflöden.
”Om du använder mäklare med egen värd, se till att de är uppdaterade till version 2.273.1 eller senare.
Enligt Wilhelm kontaktade Project Zero GitHub den 12 oktober och erbjöd dem proaktivt ett 14-dagars fönster om GitHub ville ha mer tid att inaktivera de sårbara kommandona. Naturligtvis accepterades erbjudandet och GitHub hoppades att inaktivera de sårbara kommandona efter den 19 oktober. Project Zero ställde sedan in det nya avslöjandedatumet för 2 november.
Fuente: https://bugs.chromium.org