A GitHubon egy nyílt forráskódú tárhelyen módosításokat benyújtó támadó arra késztetheti, hogy az összetevő legfrissebb verzióját tartalmazó downstream szoftverprojektek rosszindulatú kódot tartalmazó frissítéseket fordítsanak le.
Ez a Legit Security szoftverellátási lánc biztonsági cége szerint, amely egy december 1-jén közzétett tanácsában kijelentette, hogy ez a „műtermékmérgezés” gyengeség hatással lehet a GitHub Actions szolgáltatást – a fejlesztési folyamatok automatizálására szolgáló szolgáltatást – használó szoftverprojektekre azáltal, hogy elindítja az építési folyamatot, amikor változást észlel egy szoftverfüggőségben.
A biztonsági rés nem elméleti: a Legit Security egy támadást szimulált a Rustot kezelő projekt ellen, aminek következtében a projekt a népszerű GCC szoftverkönyvtár testreszabott – és rosszindulatú – verziójával újrafordításra került – szögezte le a cég a tanácsadójában.
A probléma valószínűleg számos nyílt forráskódú projektet érint, mivel a karbantartók általában tesztelik a beküldött kódot, mielőtt maguk elemeznék a kódot – mondja Liav Caspi, a Legit Security technológiai igazgatója.
„Ez manapság általános minta” – mondja. „Nagyon sok nyílt forráskódú projekt manapság egy változtatási kérelemre egy csomó tesztet lefuttat a kérés érvényesítésére, mert a karbantartó nem akarja, hogy először át kelljen néznie a kódot. Ehelyett automatikusan teszteket futtat."
A támadás a GitHub Actions szolgáltatáson keresztüli automatizált összeállítási folyamat előnyeit használja ki. A Rust programozási nyelv esetében a sérülékeny minta lehetővé tehette volna a támadó számára, hogy a fejlesztési folyamat részeként privilegizált kódot hajtson végre, ellopva az adattár titkait, és potenciálisan manipulálva a kódot – mondta a Legit Security.
"Egyszerűsítve: egy sebezhető munkafolyamatban bármely GitHub-felhasználó létrehozhat egy elágazást, amely egy műterméket épít" – áll a tanácsában. "Ezután illessze be ezt a műterméket az eredeti lerakatépítési folyamatba, és módosítsa a kimenetét. Ez a szoftverellátási lánc támadás egy másik formája, ahol a build kimenetét egy támadó módosítja.”
A sérülékenység a következőhöz hasonló támadást tesz lehetővé a CodeCovot célzó rosszindulatú programokat beszúró támadás és a vállalat szoftverén keresztül a továbbfelhasználói.
„[A] natív GitHub implementáció hiánya a munkafolyamatok közötti műtermékek kommunikációjához számos projektet és a GitHub Actions közösséget arra késztette, hogy bizonytalan megoldásokat dolgozzanak ki a munkafolyamatok közötti kommunikációhoz, és ez a fenyegetés erősen elterjedtté vált” – áll a Legit Security tanácsában.
A GitHub megerősítette a problémát, és fejpénzt fizetett az információkért, míg a Rust javította a sebezhető csővezetéket - közölte a Legit Security.
A szoftverellátási láncnak biztonságra van szüksége
A biztonsági rés a legújabb biztonsági probléma, amely a szoftverellátási láncokat érinti. Az ipar és a kormányzati szervek egyre inkább a nyílt forráskódú szoftverek és a szolgáltatásként nyújtott szoftverek biztonságának erősítésére törekedtek.
2021 májusában például a Biden-adminisztráció kiadta a nemzet kiberbiztonságának javításáról szóló végrehajtási rendeletét, amely egy szövetségi szabály, amely többek között előírja, hogy a kormány alap biztonsági szabványokat követel meg minden megvásárolt szoftverhez. A magánszektor oldalán a Google és a Microsoft rendelkezik dollármilliárdokat ígért hogy megerősítse a biztonságot a nyílt forráskódú ökoszisztémában, amely biztosítja azt a kódot, amely az átlagos alkalmazás kódbázisának több mint háromnegyedét tartalmazza.
Logikus, de sebezhető
A biztonsági probléma a logikai problémáknak nevezett problémák nehezen fellelhető osztályába tartozik, amelyek magukban foglalják az engedélyekkel kapcsolatos problémákat, az elágazott adattárak csővezetékbe való beillesztésének lehetőségét, valamint az elágazott és az alaptárolók közötti különbségtétel hiányát.
Mivel a szoftverprojektek gyakran automatizált szkripteket használnak a beküldött kódok ellenőrzésére, mielőtt azokat a karbantartóknak továbbítanák, a lekérési kérelmek automatizáláson keresztül futnak le, mielőtt az ember ellenőrizné, hogy nem tartalmaz-e rosszindulatú kódot. Bár az automatizálás időt takarít meg, azt is figyelembe kell venni, hogy a támadók rosszindulatú kódot illeszthetnek be a folyamatba.
„Amikor nyílt forráskódú fejlesztést végez, a probléma nagyobb, mert bárkitől elfogadunk hozzájárulást a világon” – mondja Caspi. "Olyan dolgokat hajtasz végre, amelyekben nem bízhatsz."
A GitHub elismerte a problémát, és kibővítette a külső együttműködőktől származó beadványok kizárásának módjait az Actions folyamatba való automatikus beillesztéstől. A cég frissítette a GetArtifact és ListArtifacts API-kat azzal a céllal, hogy több információt nyújtson annak meghatározásához, hogy egy műtermék megbízható-e.
„Bárki, aki bármit is csinál, mint a Rust projekt – bízva egy harmadik féltől származó inputban –, továbbra is sebezhető” – mondja Caspi. „Ez egy logikai probléma. A GitHub megkönnyítette a biztonságosabb szkript megírását."
