Nedavno je postalo poznato preko post na blogu, rezultati alata za testiranje za identificiranje ranjivosti bez zakrpe i identificirati sigurnosne probleme na izoliranim slikama Dockerovih spremnika.
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 sustavu, u nekim slučajevima (na primjer koristeći Snyk) s root privilegijama.
Za napad, napadač samo treba početi provjeravati svoj Dockerfile ili manifest.json, koji uključuje posebno oblikovane metapodatke, ili stavite datoteke podfile i gradlew unutar slike.
Uspijevamo pripremiti exploit prototipove za WhiteSource, Snyk, Fossa i sidrene sustave.
El paquete Claire, izvorno napisano s naglaskom na sigurnost, pokazao najbolju sigurnost.
U paketu Trivy nisu utvrđeni problemi i kao rezultat toga, zaključeno je da se skeneri Docker spremnika 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 pogreškama. Oni se bave dockerom, vade slojeve / datoteke, komuniciraju s upraviteljima paketa ili analiziraju različite formate. Njihova je obrana, iako pokušava prilagoditi sve slučajeve upotrebe programera, vrlo je teška. Pogledajmo kako različiti alati to pokušavaju i uspijevaju učiniti:
Ocjena odgovornog otkrivanja odražava moje osobno 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 su uredno obaviješteni 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 te potencijalno obavještavanje vaših kupaca. Mislim da je ovo posebno razumno pretpostaviti ako se radi o proizvodu CVE koji pruža informacije o ranjivostima u softveru. Također, uvjeravam me brzim odgovorom, razumnim vremenima korekcije i otvorenom komunikacijom s osobom koja prijavljuje napad.
U FOSSA-i, Snyku i WhiteSourceu ranjivost je bila povezana sa pozivanjem vanjskom upravitelju paketa kako biste utvrdili ovisnosti i omogućili vam da organizirate izvršavanje koda određivanjem naredbi dodira i sustava u datotekama gradlew i Podfile.
En Snyk i WhiteSource također su pronašli ranjivost povezanu s naredbama sustava 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 mjestu Anchore ranjivost je uzrokovana uporabom 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 bijega (uklonjeni su samo znakovi «; & < > ", Ali konstrukcija" $ () ").
Isti je autor proveo studiju o učinkovitosti otkrivanja ranjivosti nije zakrpan putem sigurnosnih skenera kontejnera i razina lažno pozitivnih rezultata.
Osim autora tvrdi da nekoliko ovih alata izravno koristite upravitelje paketa za rješavanje ovisnosti. To ih čini posebno teškim za obranu. 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 menadžera paketa neizbježno će značiti granatiranje novca. To, blago rečeno, ne olakšava obranu zahtjeva.
Rezultati testa 73 slike koje sadrže ranjivosti poznat, kao i procjena učinkovitosti za utvrđivanje prisutnosti tipičnih aplikacija na slikama (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), može se konzultirati u okviru objavljene publikacije U sljedećem linku.