Neseniai tapo žinoma per tinklaraščio įrašas, testavimo įrankių, skirtų nustatyti pažeidžiamumus, rezultatus nėra pleistro ir nustatykite saugumo problemas pavieniuose „Docker“ konteinerių vaizduose.
Testas parodė, kad 4 iš 6 skaitytuvų žinomi „Docker“ vaizdai turėjo kritinių pažeidžiamumų tai leido užpulti patį skaitytuvą ir paleisti jo kodą sistemoje, kai kuriais atvejais (pavyzdžiui, naudojant „Snyk“) su root teisėmis.
Dėl atakos užpuolikas tiesiog turi pradėti tikrinti savo „Dockerfile“ arba manifest.json, kuris apima specialiai suformatuotus metaduomenis, arba įdėkite „podfile“ ir „gradlew“ failus į atvaizdą.
Mums pavyksta parengti „WhiteSource“, „Snyk“, „Fossa“ ir inkarų sistemų prototipus.
El paquete Klairas, iš pradžių parašyta atsižvelgiant į saugumą, parodė geriausią saugumą.
„Trivy“ pakete nenustatyta jokių problemų ir dėl to padaryta išvada, kad „Docker“ konteinerių skaitytuvai turėtų būti naudojami izoliuotoje aplinkoje arba naudojami tik tikrinant jų pačių atvaizdus, taip pat būkite atsargūs jungdami tokius įrankius prie automatizuotų nuolatinės integracijos sistemų.
Šie skaitytuvai atlieka sudėtingus ir linkusius į klaidas veiksmus. Jie susiduria su doku, išskiria sluoksnius / failus, bendrauja su paketų tvarkytuvais arba analizuoja skirtingus formatus. Ginti juos, bandant pritaikyti visus kūrėjų naudojimo atvejus, yra labai sunku. Pažiūrėkime, kaip įvairūs įrankiai bando ir sugeba tai padaryti:
Atsakingas informacijos atskleidimo balas atspindi mano asmeninę nuomonę: manau, kad programinės įrangos tiekėjams svarbu būti imliems jiems praneštoms saugumo problemoms, būti sąžiningiems ir skaidriems dėl pažeidžiamumų, siekiant užtikrinti, kad žmonės, kurie naudojasi jų produktais, yra tinkamai informuoti priimti sprendimus dėl atnaujinimo. Tai apima svarbiausią informaciją, kad atnaujinime yra su saugumu susijusių pakeitimų, CVE atidarymas, skirtas sekti problemą ir pranešti apie ją bei potencialiai informuoti klientus. Manau, kad tai yra ypač pagrįsta manyti, jei produktas susijęs su CVE, teikiančiu informaciją apie programinės įrangos pažeidžiamumą. Be to, mane nuramina greitas reagavimas, pagrįstas taisymo laikas ir atviras bendravimas su asmeniu, pranešančiu apie užpuolimą.
FOSSA, „Snyk“ ir „WhiteSource“ pažeidžiamumas buvo susijęs su skambinimu išoriniam paketų tvarkytuvui nustatyti priklausomybes ir leisti organizuoti kodo vykdymą nurodant palietimo ir sistemos komandas gradlew ir Podfile failuose.
En „Snyk“ ir „WhiteSource“ taip pat rado pažeidžiamumą, susijusį su paleidimo sistemos komandomis organizacija, kuri analizavo „Dockerfile“ (pvz., „Snyk“ per „Dockefile“ galite pakeisti skaitytuvo sukurtą įrankį „ls“ (/ bin / ls), o „WhiteSurce“ galite pakeisti kodą naudodamiesi argumentais „aido“ forma. ; palieskite /tmp/hacked_whitesource_pip;=1.0 '«).
Anchore pažeidžiamumą sukėlė naudojimasis „skopeo“ programa dirbti su dokų vaizdais. Operacija buvo sumažinta, įtraukiant formos »» os »:« $ (touch hacked_anchore) »'parametrus į manifest.json failą, kurie pakeičiami iškviečiant skopeo be tinkamo pabėgimo (buvo pašalinti tik simboliai«; & < > ", Bet konstruktas" $ () ").
Tas pats autorius atliko pažeidžiamumo nustatymo efektyvumo tyrimą neužlopytas per saugos skaitytuvus konteinerių konteinerių kiekis ir klaidingai teigiamų rezultatų lygis.
Be autoriaus teigia, kad keletas šių priemonių tiesiogiai naudokite paketų tvarkykles, kad išspręstumėte priklausomybes. Dėl to juos ypač sunku apginti. Kai kurie priklausomybės valdytojai turi konfigūracijos failus, leidžiančius įtraukti apvalkalo kodą.
Net jei šie paprasti būdai yra kažkaip tvarkomi, paskambinus šiems paketų valdytojams, neišvengiamai reikės išmesti pinigus. Tai, švelniai tariant, nepalengvina ieškinio gynimo.
Bandomieji 73 vaizdų, kuriuose yra pažeidžiamumų, rezultatai žinomas, taip pat veiksmingumo įvertinimas siekiant nustatyti tipiškų vaizdų (nginx, runc, haproxy, gunicorn, redis, ruby, node) buvimą paveikslėliuose, galima kreiptis padaryto leidinio ribose Šioje nuorodoje.