{"id":118226,"date":"2024-07-25T15:43:00","date_gmt":"2024-07-25T13:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki"},"modified":"2024-07-25T15:43:00","modified_gmt":"2024-07-25T13:43:02","slug":"dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/novosti-interneta\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","title":{"rendered":"Ligip\u00e4\u00e4s tegevuse andmetele kaug- ja privaatsetest Repositooriumidest GitHubis, millel on forkid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Truffle Security avaldas r\u00fcnnakuskeemid mitmete t\u00fc\u00fcpiliste GitHubi repositooriumide t\u00f6\u00f6tlusmeetodite kohta, mis v\u00f5imaldavad andmeid v\u00e4lja t\u00f5mmata kaugrepositooriumitest, millel on avalikud forkid v\u00f5i millel on m\u00f5ni forkk loodud. <\/p>\n
Repo forkide olevate commit'ide juurdep\u00e4\u00e4su v\u00f5imalus hash'i kaudu on p\u00f5hjustatud sellest, et GitHub optimeerimise ja duplikaatide v\u00e4ltimise eesm\u00e4rgil salvestab k\u00f5ik pearepo ja forkide objektid koos, jagades ainult loogiliselt commit'ide kuuluvust. Selline salvestamine v\u00f5imaldab pearepos igat commit'it igast forkist vaadata, kui URL-is on selgelt n\u00e4idatud selle hash. N\u00e4iteks v\u00f5ib kasutaja luua fork'i repolt \"\/torvalds\/linux\" ja lisada sinna mis tahes koodi, p\u00e4rast mida on see kood saadaval otse hash-viidena repol \"\/torvalds\/linux\". Kui repositoorium on kustutatud, j\u00e4\u00e4vad kustutatud repositooriumi andmed kergesti k\u00e4ttesaadavaks, kui on v\u00e4hemalt \u00fcks avalik fork. <\/p>\n
Pakutakse kolme stsenaariumi, mis esindavad turvaohtu: <\/p>\n
\n
Esimene stsenaarium k\u00e4sitleb olukordi, kus arendajad loovad avalike repode koopiad, teevad neis muudatusi, katsetavad ja seej\u00e4rel kustutavad. Peale koodi lekke, mis pole m\u00f5eldud avaldamiseks, kujutab ohtu olukord, kus katsetades lisatakse n\u00e4idifailide koodi t\u00f6\u00f6tavaid API ligip\u00e4\u00e4suv\u00f5tmeid. Sel juhul v\u00f5ib r\u00fcndaja saavutada ligip\u00e4\u00e4su eemaldatud forki kaudu p\u00f5hirepositooriumi suunatud commit hash'i j\u00e4rgi. N\u00e4iteks suudeti pakutud viisil teadlastel m\u00e4\u00e4rata 30 t\u00f6\u00f6tavat API ligip\u00e4\u00e4suv\u00f5tit, uurides kolme masin\u00f5ppega seotud repot, millel on suur hulk forke.\n
Teine stsenaarium k\u00e4sitleb andmete ligip\u00e4\u00e4su saamise v\u00f5imalust p\u00e4rast esmase hoidla kustutamist, kui selle hoidla kohta on loodud harud. N\u00e4iteks tuuakse juhtum, kus \u00fche ettev\u00f5tte avalikus hoidlus avaldati juhuslikult \u00fche t\u00f6\u00f6taja suletud v\u00f5tmed, mis andsid t\u00e4ieliku ligip\u00e4\u00e4su k\u00f5igile selle ettev\u00f5tte hoidlatele GitHubis. Ettev\u00f5te kustutas hoidla, mille kaudu andmed lekkisid, kuid v\u00f5tmed j\u00e4id endiselt kergesti k\u00e4tte saadavaks, kui neid otsiti commit'i hash'i abil harudest.
<\/center>\n
Kolmas stsenaarium on seotud projektide arendamise mudeliga, kus p\u00f5hiversioon areneb avalikus hoidlas ja laiendatud omadustega versioon privaatsetes. Kui ettev\u00f5te algselt arendas projekti privaatsetes hoidlates, kuid seej\u00e4rel avas koodi ja t\u00f5i projekti avalikku hoidlasse, j\u00e4tkates siiski suletud sise- v\u00f5i laiendatud versiooni arendamist privaatse fork'iga, on v\u00f5imalik juurde p\u00e4\u00e4seda privaatse forki lisatud muudatustele commit'i hash'ide kaudu avaliku hoidla kaudu. Samas on juurdep\u00e4\u00e4s v\u00f5imalik ainult nendele muudatustele, mis lisati privaatsele fork'ile enne p\u00f5hihoidla \u00fcleviimist avalikuks (privaatsete ja avalike hoidlate salvestised on eraldi, kuid kui kaks hoidlat olid privaatset, salvestati commit'id koos, seega j\u00e4id need hoidlasse p\u00e4rast selle \u00fcleviimist avalikuks).
<\/center> <\/ul>\n
Trikk, mis v\u00f5imaldab ligip\u00e4\u00e4su reposti forkide commit'idele peamiste reposte kaudu, on tuntud juba aastaid ja seda kasutatakse perioodiliselt erinevate nali ja arendajate petmiseks (n\u00e4iteks naljamehed loovad sageli selliselt mulje, et nad paigutavad Linuxi tuuma reposti backdoore GitHubis). Nende naljade vastu v\u00f5itlemiseks on GitHub lisanud hoiatuse, et taotletud commit ei kuulu k\u00e4esoleva reposti harudesse ja v\u00f5ib kuuluda forkile. Samuti peeti forkide kaudu commit'idele juurdep\u00e4\u00e4su v\u00f5imalust s\u00fc\u00fctuks, kuna andmete saamiseks eemaldates ja privaatsetes forkides on vajalik commit'i hash'i teadmine. <\/p>\n
Commit'i hash, mis loodi SHA-1 algoritmi alusel ja sisaldab 32 s\u00fcmbolit, on praktiliselt v\u00f5imatu leida, kuid selgus, et seda ei olegi vaja. GitHub toetab l\u00fchendatud viisi commit'ide adresseerimiseks, v\u00f5imaldades suunata muudatused m\u00f5nele esimesele hash'i s\u00fcmbolile, kui ei esine \u00fchtesid commit'e. L\u00fchendatud hash'i adresseerimise minimaalne s\u00fcmbolite arv on 4, mis vastab 65 tuhande kombinatsiooni (16^4) katsele. Samas ei pruugi see katse vajalik olla, kuna GitHubi API v\u00f5imaldab \u00fchendada t\u00f6\u00f6tlejaid s\u00fcndmuste p\u00fc\u00fcdmiseks, mida kasutavad kolmandate osapoolte projektid, kes peavad arhiivi, millel on t\u00e4ielik logi k\u00f5ikidest toimingutest, kus commit'ide hash'id j\u00e4\u00e4vad alles ka p\u00e4rast repositooriumide kustutamist. \n Allikas: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Ligip\u00e4\u00e4s](\"\/wp-content\/uploads\/2024\/07\/45381deb03eaa5be40baf8b4dbf7b481.png\")
<\/center>\n![\"Ligip\u00e4\u00e4s](\"\/wp-content\/uploads\/2024\/07\/23342cf907bd300699e913297d29b310.png\")
<\/center> <\/ul>\n