Kohët e fundit u bë e njohur Mediante një postim në blog, rezultatet e mjeteve të testimit për të identifikuar dobësitë pa patch dhe identifikoni çështjet e sigurisë në imazhet e izoluara të kontejnerëve Docker.
Testi tregoi se 4 nga 6 skanuesit imazhe të njohura Docker kishin dobësi kritike që lejoi të sulmonte vetë skanerin dhe të ekzekutonte kodin e tij në sistem, në disa raste (duke përdorur Snyk për shembull) me privilegje root.
Për një sulm, një sulmues duhet vetëm të fillojë të kontrollojë Dockerfile-in e tij ose manifest.json, i cili përfshin të meta të dhëna të formatuara posaçërisht, ose vendosni skedarët Podfile dhe gradlew brenda imazhit.
Ne kemi arritur të përgatisim prototipet e shfrytëzimit për WhiteSource, Snyk, Fossa dhe sistemet e ankorimit.
El paquete Klir, shkruar fillimisht me siguri në mendje, tregoi sigurinë më të mirë.
Nuk ka probleme të identifikuara në paketën Trivy dhe si rezultat, u konkludua që skanuesit e kontejnerëve Docker duhet të ekzekutohen në mjedise të izoluara ose të përdoren vetëm për të verifikuar imazhet e tyre, dhe gjithashtu të jenë të kujdesshëm kur lidhni mjete të tilla me sisteme të integruara të automatizuara të vazhdueshme.
Këta skanues bëjnë gjëra të komplikuara dhe të prirura për gabime. Ata kanë të bëjnë me docker, duke nxjerrë shtresa / skedarë, duke ndërvepruar me menaxherët e paketave ose duke analizuar formate të ndryshme. Mbrojtja e tyre, ndërsa përpiqet të akomodojë të gjitha rastet e përdorimit për zhvilluesit, është shumë e vështirë. Le të shohim se si mjetet e ndryshme përpiqen dhe arrijnë ta bëjnë atë:
Rezultati i zbulimit përgjegjës pasqyron mendimin tim personal: Unë mendoj se është e rëndësishme që shitësit e programeve kompjuterikë të reagojnë ndaj çështjeve të sigurisë që u raportohen atyre, të jenë të sinqertë dhe transparent në lidhje me dobësitë, për të siguruar që njerëzit që përdorin produktet e tyre të jenë të informuar si duhet për të bërë vendimet në lidhje me azhurnimin. Kjo përfshin informacionin më të rëndësishëm që një azhurnim ka ndryshime në lidhje me sigurinë, duke hapur një CVE për të gjurmuar dhe komunikuar në lidhje me problemin dhe potencialisht të njoftojë klientët tuaj. Unë mendoj se kjo është veçanërisht e arsyeshme të supozohet nëse produkti ka të bëjë me CVE, duke siguruar informacion në lidhje me dobësitë në softuer. Gjithashtu, unë sigurohem nga reagimi i shpejtë, kohët e arsyeshme të korrigjimit dhe komunikimi i hapur me personin që raporton sulmin.
Në FOSSA, Snyk dhe WhiteSource, cenueshmëria ishte e lidhur me thirrje tek një menaxher i jashtëm i paketave për të përcaktuar varësitë dhe për t'ju lejuar të organizoni ekzekutimin e kodit tuaj duke specifikuar komandat e prekjes dhe sistemit në skedarët gradlew dhe Podfile.
En Snyk dhe WhiteSource gjithashtu gjetën një dobësi, të lidhur me komandat e sistemit të nisjes organizatë që analizoi Dockerfile (për shembull, në Snyk përmes Dockefile mund të zëvendësoni programin ls (/ bin / ls), të shkaktuar nga skaneri dhe në WhiteSurce mund të zëvendësoni kodin përmes argumenteve në formën e "echo"; prekni / tmp / hacked_whitesource_pip; = 1.0 '«).
Në Anchore, cenueshmëria u shkaktua nga përdorimi i ndërmarrjes skopeo për të punuar me imazhe docker. Operacioni u reduktua në shtimin e parametrave të formës '»os»: «$ (prekni hacked_anchore)» në skedarin manifest.json, të cilat zëvendësohen kur telefononi skopeo pa një ikje të duhur (vetëm karakteret «; & <u hoqën > ", Por konstrukti" $ () ").
I njëjti autor kreu një studim mbi efektivitetin e zbulimit të cenueshmërisë jo i arnuar përmes skanerëve të sigurisë të kontejnerëve docker dhe niveli i pozitiveve false.
Përveç autorit argumenton se disa nga këto mjete përdorni drejtpërdrejt menaxherët e paketave për të zgjidhur varësitë. Kjo i bën ata veçanërisht të vështirë për t'u mbrojtur. Disa menaxherë të varësisë kanë skedarë konfigurimi që lejojnë përfshirjen e kodit shell.
Edhe nëse trajtohen disi këto mënyra të thjeshta, thirrja e këtyre menaxherëve të paketës do të thotë në mënyrë të pashmangshme mbledhja e parave. Kjo, për ta thënë butë, nuk lehtëson mbrojtjen e kërkesës.
Rezultatet e provës për 73 imazhe që përmbajnë dobësi i njohur, si dhe një vlerësim i efektivitetit për të përcaktuar praninë e aplikacioneve tipike në imazhe (nginx, tomcat, haproxy, gunicorn, redis, rubin, nyje), mund të konsultohet brenda botimit të bërë Në lidhjen vijuese.