Пројецт Зеро објавио је детаље озбиљног нарушавања безбедности на ГитХуб-у и они то пријављују грешка утиче на наредбе тока радње акције са ГитХуб-а и описује се као озбиљан. (Ова грешка је откривена у јулу, али на основу стандардног периода откривања од 90 дана, детаљи су објављени тек сада.)
Ова мана је постала једна од ретких рањивости која није отклоњена правилно пре истека стандардног временског оквира од 90 дана који је одобрио Гоогле Пројецт Зеро.
Према Феликсу Вилхелму (који је то открио), члан тима Пројецт Зеро, мана утиче на функцију ГитХуб Ацтионс, алатку за аутоматизацију рада програмера. То је зато што су команде радног тока „Ацтион“ рањиве на нападе убризгавањем:
„Акције Гитхуб подржава функцију која се назива наредбе тока посла као комуникациони канал између посредника радњи и извршене акције. Наредбе тока посла имплементиране су у / срц / Руннер.Воркер / АцтионЦоммандМанагер.цс и то функционира рашчлањивањем СТДОУТ свих радњи извршених тражењем једног од два маркера команди.
Спомените то велики проблем ове функције је што је веома осетљива на нападе ињекцијама. Будући да поступак извршења скенира сваки ред одштампан у СТДОУТ за наредбе тока посла, свака ГитХуб акција која садржи непоуздани садржај као део њеног извршавања је рањива.
У већини случајева способност постављања произвољних променљивих околине резултира даљинским извршавањем кода чим се покрене други ток посла. Провео сам неко време гледајући популарна ГитХуб спремишта и скоро сваки пројекат који користи помало сложене ГитХуб акције рањив је на ову врсту грешке.
Касније дао неколико примера како се грешка може искористити и такође предложио решење:
„Заиста нисам сигуран који је најбољи начин да се то поправи. Мислим да је начин примене наредби тока посла у основи несигуран. Амортизација в1 синтаксе команде и јачање сет-енв са листом дозвола вероватно би функционисало против директних РЦЕ вектора.
„Међутим, чак је и способност надјачавања„ нормалних “променљивих окружења коришћених у каснијим корацима вероватно довољна да искористи сложеније акције. Нити сам анализирао утицај других контрола у радном простору на безбедност.
Са друге стране, напоменути да је добро дугорочно решење Било би премештање наредби тока посла у засебни канал (нпр. Нови дескриптор датотеке) како би се избегло рашчлањивање помоћу СТДОУТ-а, али то ће разбити пуно постојећег акционог кода.
Што се тиче ГитХуб-а, његови програмери објавили су савет 1. октобра и одбацили рањиве команде, али тврдили су да је оно што је Вилхелм открио заправо „умерена безбедносна рањивост“. ГитХуб је доделио идентификатор грешке ЦВЕ-2020-15228:
„Утврђена је умерена сигурносна рањивост у рунтиме-у ГитХуб Ацтионс која може омогућити убризгавање путања и променљивих околине у токове рада који непоуздане податке евидентирају у СТДОУТ. То може довести до увођења или модификовања променљивих околине без намере аутора радног процеса.
„Да бисмо нам помогли да решимо овај проблем и омогућимо вам да динамички подесите променљиве окружења, увели смо нови скуп датотека за руковање ажурирањима окружења и путања у радним токовима.
„Ако користите посреднике који сами хостују, уверите се да су ажурирани на верзију 2.273.1 или новију.
Према Вилхелму, 12. октобра Пројецт Зеро је контактирао ГитХуб и проактивно им понудио 14-дневни прозор ако ГитХуб жели више времена да онемогући рањиве команде. Наравно, понуда је прихваћена и ГитХуб се надао да ће онемогућити рањиве команде након 19. октобра. Тада је Пројецт Зеро одредио нови датум објављивања за 2. новембар.
izvor: https://bugs.chromium.org