Pred kratkim je postalo znano skozi objava v spletnem dnevniku, rezultate preizkusnih orodij za prepoznavanje ranljivosti brez popravka in prepoznavanje varnostnih težav v izoliranih slikah posod Docker.
Test je pokazal, da 4 od 6 skenerjev znane Dockerjeve slike imel kritične ranljivosti ki je omogočil napad samega optičnega bralnika in izvajanje njegove kode v sistemu, v nekaterih primerih (na primer s Snykom) s korenskimi privilegiji.
Za napad, napadalec mora samo začeti preverjati svojo Dockerfile ali manifest.json, ki vključuje posebej oblikovane metapodatke, ali vstavite datoteke podfile in gradlew znotraj slike.
Uspeli smo pripraviti exploit prototipe za sisteme WhiteSource, Snyk, Fossa in sidrišča.
El paquete Clair, prvotno napisano z mislijo na varnost, pokazal najboljšo varnost.
V paketu Trivy ni nobenih težav in posledično je bilo sklenjeno, da je treba Dockerjeve skenerje zabojnikov zagnati v izoliranih okoljih ali uporabljati samo za preverjanje lastnih slik, prav tako pa bodite previdni pri povezovanju takšnih orodij z avtomatiziranimi sistemi za neprekinjeno integracijo.
Ti optični bralniki delajo zapletene stvari in nagnjene k napakam. Ukvarjajo se z dockerjem, pridobivanjem plasti / datotek, interakcijo z upravitelji paketov ali analiziranjem različnih formatov. Njihova obramba, medtem ko poskuša razvijalcem prilagoditi vse primere uporabe, je zelo težka. Poglejmo, kako različna orodja to poskušajo in uspejo:
Ocena odgovornega razkritja odraža moje osebno mnenje: menim, da je pomembno, da so prodajalci programske opreme dovzetni za varnostna vprašanja, ki so jim bila sporočena, da so pošteni in pregledni glede ranljivosti, da zagotovijo, da so ljudje, ki uporabljajo njihove izdelke, ustrezno obveščeni o sprejemanju odločitev o posodobitvi. Sem spadajo glavne informacije, da ima posodobitev spremembe, povezane z varnostjo, odpiranje CVE za sledenje in obveščanje o težavi ter potencialno obveščanje strank. Mislim, da je to še posebej smiselno domnevati, če gre za izdelek o CVE, ki zagotavlja informacije o ranljivosti v programski opremi. Prav tako me pomirjajo hiter odziv, razumni popravni časi in odprta komunikacija z osebo, ki poroča o napadu.
Pri FOSSA, Snyk in WhiteSource je bila ranljivost povezana s klicanjem zunanjemu upravitelju paketov za določitev odvisnosti in omogočanje organiziranja izvajanja kode z določitvijo ukazov na dotik in sistema v datotekah gradlew in Podfile.
En Snyk in WhiteSource sta našla tudi ranljivost, povezano z ukazi sistema za zagon organizacija, ki je razčlenila Dockerfile (na primer v Snyk prek Dockefile lahko nadomestite pripomoček ls (/ bin / ls), ki ga povzroči optični bralnik, v WhiteSurce pa lahko kodo nadomestite z argumenti v obliki "echo"; tapnite / tmp / hacked_whitesource_pip; = 1.0 '«).
V Anchoreju je ranljivost povzročila uporaba pripomočka skopeo za delo s slikami dockerjev. Operacija se je zmanjšala na dodajanje parametrov obrazca '»os»: «$ (touch hacked_anchore)»' v datoteko manifest.json, ki se nadomestijo med klicem skopeo brez ustreznega pobega (odstranjeni so bili samo znaki «; & < > ", Ampak konstrukt" $ () ").
Isti avtor je izvedel študijo o učinkovitosti odkrivanja ranljivosti ni zakrpan prek varnostnih skenerjev kontejnerjev in raven lažno pozitivnih rezultatov.
Poleg avtorja trdi, da je več teh orodij neposredno uporabite upravitelje paketov za reševanje odvisnosti. Zaradi tega jih je še posebej težko braniti. Nekateri upravitelji odvisnosti imajo konfiguracijske datoteke, ki omogočajo vključitev lupinske kode.
Tudi če se s temi preprostimi načini nekako reši, bo klicanje teh upraviteljev paketov neizogibno pomenilo lupljenje denarja. To, milo rečeno, ne olajša obrambe tožbe.
Rezultati testa 73 slik, ki vsebujejo ranljivosti kot tudi ocena učinkovitosti za ugotavljanje prisotnosti tipičnih aplikacij na slikah (nginx, tomcat, haproxy, gunicorn, redis, ruby, vozlišče), se lahko posvetujete znotraj objavljene objave V naslednji povezavi.