Fa poc es va donar a conèixer mitjançant una publicació de bloc, els resultats de les eines de prova per identificar vulnerabilitats sense pegat i identificar problemes de seguretat en imatges de contenidors Docker aïllats.
La prova va mostrar que 4 dels 6 escàners d'imatges de Docker coneguts tenien vulnerabilitats crítiques que permetien atacar l'escàner en si i executar el seu codi en el sistema, en alguns casos (per exemple, a l'usar Snyk) amb privilegis de root.
Per a un atac, un atacant només necessita iniciar la verificació del seu Dockerfile o manifest.json, que inclou metadades amb format especial, o col·locar els arxius Podfile i gradlew dins de la imatge.
Ens les arreglem per preparar explotar prototips per WhiteSource, Snyk, Fossa i sistemes anchore.
El paquete Clair, que originalment es va escriure pensant en la seguretat, va mostrar la millor seguretat.
No es van identificar problemes en el paquet Trivy i com a resultat, es va concloure que els escàners de contenidors de Docker s'han d'executar en entorns aïllats o usar-se només per verificar les seves pròpies imatges, i també tenir cura a l'connectar aquestes eines a sistemes d'integració contínua automatitzats.
Aquests escàners fan coses complicades i propenses a errors. Estan bregant amb la finestra acoblable, extraient capes / arxius, interactuant amb administradors de paquets o analitzant diferents formats. Defensar-los, mentre s'intenta donar cabuda a tots els casos d'ús per als desenvolupadors, és molt difícil. Vegem com les diferents eines intenten i aconsegueixen fer-ho:
El puntuació en la divulgació responsable reflecteix la meva opinió personal: crec que és important que els proveïdors de programari siguin receptius als problemes de seguretat que se'ls informen, siguin honestos i transparents sobre les vulnerabilitats, per assegurar-se que les persones que utilitzen els seus productes estiguin degudament informades per prendre decisions sobre l'actualització. Això inclou la informació més important que una actualització té canvis rellevants per a la seguretat, obrir un CVE per rastrejar i comunicar-se sobre el problema i potencialment notificar als seus clients. Crec que és especialment raonable suposar això si el producte tracta sobre CVE, proporcionant informació sobre vulnerabilitats en el programari. A més, em tranquil·litza la resposta ràpida, els temps de correcció raonables i la comunicació oberta amb la persona que divulga l'atac.
En FOSSA, Snyk i WhiteSource, la vulnerabilitat estava relacionada amb cridar a un administrador de paquets extern per determinar les dependències i permetre-organitzar l'execució del seu codi especificant les ordres tàctils i de el sistema en els arxius gradlew i Podfile.
En Snyk i WhiteSource es va trobar a més una vulnerabilitat, associada amb les ordres de sistema de llançament de l'organització que analitzaven Dockerfile (per exemple, en Snyk a través d'Dockefile podria reemplaçar la utlidad ls (/ bin / ls), causat per l'escàner i en WhiteSurce podria reemplaçar el codi a través dels arguments en forma de «echo ' ; toc /tmp/hacked_whitesource_pip;=1.0 ' «).
En Anchore, la vulnerabilitat va ser causada per l'ús de la utilitat skopeo per treballar amb imatges de docker. L'operació es va reduir a afegir paràmetres de la forma ' »us»: «$ (touch hacked_anchore)»' a l'arxiu manifest.json, que substitueixen el cridar a skopeo sense una fuita adequat (només es van eliminar els caràcters «; & < > », però la construcció« $ () «).
El mateix autor va realitzar un estudi sobre l'eficàcia de la detecció de vulnerabilitats no pegats mitjançant escàners de seguretat de contenidors docker i el nivell de falsos positius.
A més l'autor argumenta que diverses d'aquestes eines utilitzen directament administradors de paquets per resoldre dependències. Això els fa particularment difícils de defensar. Alguns administradors de dependències tenen arxius de configuració que permeten la inclusió de codi shell.
Fins i tot si d'alguna manera es manegen aquestes formes senzilles, trucar a aquests administradors de paquets significarà inevitablement desemborsar diners. Això, per dir-ho suaument, no facilita la defensa de l'aplicació.
Els resultats de les proves de 73 imatges que contenen vulnerabilitats conegudes, així com una avaluació de l'efectivitat per determinar la presència d'aplicacions típiques en imatges (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), poden ser consultades dins de la publicació realitzada en el següent enllaç.