Inilabas ng Project Zero ang mga detalye ng isang seryosong paglabag sa seguridad sa GitHub at iniulat nila iyon nakakaapekto ang error sa mga utos ng daloy ng trabaho mula sa GitHub at inilarawan bilang mataas na kalubhaan. (Ang bug na ito ay natuklasan noong Hulyo, ngunit sa ilalim ng karaniwang 90-araw na panahon ng pagsisiwalat, ang mga detalye ay inilabas lamang ngayon.)
Ang kapintasan na ito ay naging isa sa ilang mga kahinaan na hindi naayos maayos bago mag-expire ang karaniwang 90-araw na timeframe na ibinigay ng Google Project Zero.
Ayon kay Felix Wilhelm (na natuklasan ito), ang kasapi ng koponan ng Project Zero, ang kapintasan ay nakakaapekto sa pagpapaandar ng mga aksyon ng GitHub, isang tool upang i-automate ang gawain ng mga developer. Ito ay dahil ang mga pagkilos na mga utos ng daloy ng trabaho ay "mahina laban sa mga pag-atake ng iniksyon":
"Sinusuportahan ng Mga Pagkilos na Github ang isang tampok na tinatawag na mga utos ng daloy ng trabaho bilang isang channel ng komunikasyon sa pagitan ng Action broker at ng pinaandar na pagkilos. Ang mga utos ng workflow ay ipinatupad sa / src / Runner.Worker / ActionCommandManager.cs at gumagana ito sa pamamagitan ng pag-parse ng STDOUT ng lahat ng mga aksyon na isinagawa sa pamamagitan ng pagtingin sa isa sa dalawang mga marker ng utos.
Banggitin mo yan ang malaking problema sa tampok na ito ay na ito ay napaka-mahina laban sa pag-atake ng iniksyon. Sapagkat sinusuri ng proseso ng pagpapatupad ang bawat hilera na naka-print sa STDOUT para sa mga utos ng daloy ng trabaho, ang bawat pagkilos na GitHub na naglalaman ng hindi pinagkakatiwalaang nilalaman bilang bahagi ng pagpapatupad nito ay madaling maapektuhan.
Sa karamihan ng mga kaso, ang kakayahang magtakda ng di-makatwirang mga variable ng kapaligiran ay nagreresulta sa pagpapatupad ng remote code sa sandaling tumatakbo ang isa pang daloy ng trabaho. Gumugol ako ng ilang oras sa pagtingin sa mga tanyag na repository ng GitHub at halos anumang proyekto na gumagamit ng bahagyang kumplikadong mga pagkilos ng GitHub ay mahina laban sa ganitong uri ng bug.
Mamaya nagbigay ng ilang mga halimbawa kung paano maaaring samantalahin ang bug at nagmungkahi din ng solusyon:
"Hindi talaga ako sigurado kung ano ang pinakamahusay na paraan upang ayusin ito. Sa palagay ko ang paraan ng pagpapatupad ng mga utos ng daloy ng trabaho ay sa pangkalahatan ay walang katiyakan. Ang pagpapahalaga sa syntax ng v1 ng utos at pagpapalakas ng env na may isang pinapayagan na listahan ay maaaring gumana laban sa direktang mga RCE vector.
"Gayunpaman, kahit na ang kakayahang i-override ang 'normal' na mga variable ng kapaligiran na ginamit sa mga susunod na hakbang ay malamang na sapat upang pagsamantalahan ang mas kumplikadong mga pagkilos. Ni sinuri ko ang epekto sa seguridad ng iba pang mga kontrol sa workspace.
Sa kabilang banda, banggitin na ang isang mahusay na pangmatagalang solusyon Ito ay upang ilipat ang mga utos ng daloy ng trabaho sa isang hiwalay na channel (hal. Isang bagong tagapaglarawan ng file) upang maiwasan ang pag-parse ng STDOUT, ngunit masisira nito ang maraming umiiral na code ng pagkilos.
Tulad ng para sa GitHub, ang mga developer nito ay nag-post ng isang payo noong Oktubre 1 at tinanggal ang mga mahina na utos, ngunit pinangatwiran na ang natagpuan ni Wilhelm sa katunayan ay isang "katamtamang kahinaan sa seguridad." Itinalaga ni GitHub ang tagatukoy ng bug na CVE-2020-15228:
"Ang isang katamtamang kahinaan sa seguridad ay nakilala sa runtime ng Mga Aksyon ng GitHub na maaaring payagan ang pag-iniksyon ng mga landas at variable ng kapaligiran sa mga daloy ng trabaho na nag-log ng hindi pinagkakatiwalaang data sa STDOUT. Maaari itong humantong sa pagpapakilala o pagbabago ng mga variable ng kapaligiran nang walang hangarin ng may-akda ng daloy ng trabaho.
"Upang matulungan kaming malutas ang problemang ito at payagan kang mailipat nang pabagu-bago ang mga variable ng kapaligiran, nagpakilala kami ng isang bagong hanay ng mga file upang mahawakan ang mga pag-update sa kapaligiran at landas sa mga daloy ng trabaho.
"Kung gumagamit ka ng mga self-host na broker, tiyaking nai-update ang mga ito sa bersyon 2.273.1 o mas mataas.
Ayon kay Wilhelm, noong Oktubre 12, nakipag-ugnay ang Project Zero sa GitHub at maagap na inalok sa kanila ng 14 na araw na deadline kung nais ng GitHub ng mas maraming oras upang hindi paganahin ang mga mahina na utos. Siyempre, tinanggap ang alok at inaasahan ni GitHub na huwag paganahin ang mga mahihinang utos pagkatapos ng Oktubre 19. Pagkatapos ay itinakda ng Project Zero ang bagong petsa ng pagsisiwalat para sa Nobyembre 2.
Fuente: https://bugs.chromium.org