Nedavno postalo poznato Mediante post na blogu, rezultati alata za testiranje za identifikaciju ranjivosti nema zakrpe i identifikujte sigurnosne probleme na izoliranim slikama Dockerovih kontejnera.
Test je pokazao da 4 od 6 skenera poznate Dockerove slike imao kritične ranjivosti to je omogućilo napad na sam skener i pokretanje njegovog koda na sistemu, u nekim slučajevima (na primjer koristeći Snyk) s root privilegijama.
Za napad, napadač samo treba započeti provjeru svog Dockerfile-a ili manifest.json, koji uključuje posebno formatirane metapodatke, ili stavite datoteke Podfile i gradlew unutar slike.
Uspijevamo pripremiti eksploatacijske prototipove za WhiteSource, Snyk, Fossa i sidrene sisteme.
Paket Claire, izvorno napisano sa pažnjom o sigurnosti, pokazao najbolju sigurnost.
U paketu Trivy nisu utvrđeni problemi i kao rezultat toga, zaključeno je da se skeneri Docker kontejnera trebaju pokretati u izoliranim okruženjima ili koristiti samo za provjeru vlastitih slika, a također biti oprezan pri povezivanju takvih alata s automatiziranim sustavima kontinuirane integracije.
Ovi skeneri rade složene stvari i podložne greškama. Oni se bave dockerom, vade slojeve / datoteke, komuniciraju s upraviteljima paketa ili analiziraju različite formate. Braniti ih, dok pokušavaju prilagoditi sve slučajeve upotrebe programera, vrlo je teško. Pogledajmo kako različiti alati to pokušavaju i uspijevaju:
Ocjena odgovornog otkrivanja odražava moje lično mišljenje: Mislim da je važno da dobavljači softvera budu prihvatljivi za sigurnosna pitanja koja su im prijavljena, da budu iskreni i transparentni u pogledu ranjivosti, kako bi osigurali da ljudi koji koriste njihove proizvode budu pravilno informirani da donose odluke o ažuriranju. To uključuje najvažnije informacije da ažuriranje ima sigurnosne promjene, otvaranje CVE-a za praćenje i komuniciranje o problemu i potencijalno obavještavanje kupaca. Mislim da je ovo posebno razumno pretpostaviti ako se radi o proizvodu CVE koji pruža informacije o ranjivostima u softveru. Takođe, uveravam me brzim odgovorom, razumnim vremenima korekcije i otvorenom komunikacijom sa osobom koja prijavljuje napad.
U FOSSA-i, Snyk-u i WhiteSource-u ranjivost je bila povezana sa pozivanjem vanjskom upravitelju paketa da odredite zavisnosti i omogućite vam da organizirate izvršavanje vašeg koda specificiranjem dodirnih i sistemskih naredbi u datotekama gradlew i Podfile.
En Snyk i WhiteSource također su pronašli ranjivost povezanu s naredbama sistema za lansiranje organizacija koja je raščlanila Dockerfile (na primjer, u Snyk-u putem Dockefile-a možete zamijeniti uslužni program ls (/ bin / ls), uzrokovan skenerom, a u WhiteSurceu možete zamijeniti kôd putem argumenata u obliku "echo"; dodirnite / tmp / hacked_whitesource_pip; = 1.0 '«).
U Anchoreu je ranjivost uzrokovana upotrebom uslužnog programa skopeo za rad sa slikama dockera. Operacija je svedena na dodavanje parametara oblika '»os»: «$ (touch hacked_anchore)»' u datoteku manifest.json, koji se zamjenjuju pri pozivu skopeo bez odgovarajućeg escape-a (uklonjeni su samo znakovi «; & < > ", Ali konstrukcija" $ () ").
Isti autor proveo je studiju o efikasnosti otkrivanja ranjivosti nije zakrpan putem sigurnosnih skenera kontejnera i nivo lažno pozitivnih rezultata.
Pored autora tvrdi da nekoliko ovih alata izravno koristite upravitelje paketa za rješavanje zavisnosti. To ih čini posebno teškim za odbranu. Neki upravitelji ovisnosti imaju konfiguracijske datoteke koje omogućuju uključivanje školjkastog koda.
Čak i ako se nekako riješe ovi jednostavni načini, pozivanje ovih menadžera paketa neizbježno će značiti granatiranje novca. To, blago rečeno, ne olakšava odbranu prijave.
Rezultati testa za 73 slike koje sadrže ranjivosti poznat, kao i procjena efikasnosti za utvrđivanje prisustva tipičnih aplikacija na slikama (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), mogu se konsultovati u okviru objavljene publikacije Na sledećem linku.