Recentemente coñeceuse a través unha publicación no blog, os resultados das ferramentas de proba para identificar vulnerabilidades sen parche e identificar problemas de seguridade en imaxes de contedores Docker illadas.
A proba mostrou que 4 dos 6 escáneres imaxes coñecidas de Docker tiña vulnerabilidades críticas que permitiu atacar ao propio escáner e executar o seu código no sistema, nalgúns casos (usando Snyk por exemplo) con privilexios de root.
Por un ataque, un atacante só precisa comezar a comprobar o seu ficheiro Docker ou manifest.json, que inclúe metadatos especialmente formateados, ou coloque os ficheiros podfile e gradlew dentro da imaxe.
Conseguimos preparar prototipos de explotación para WhiteSource, Snyk, Fossa e sistemas de ancoraxe.
O paquete Claire, escrito orixinalmente pensando na seguridade, mostrou a mellor seguridade.
Non se identificaron problemas no paquete Trivy e como resultado, concluíuse que os escáneres de contedores Docker deberían executarse en ambientes illados ou usarse só para verificar as súas propias imaxes, e tamén ter coidado ao conectar esas ferramentas a sistemas de integración continua automatizados.
Estes escáneres fan cousas complicadas e con erros. Están lidando co docker, extraendo capas / ficheiros, interactuando cos xestores de paquetes ou analizando diferentes formatos. Defenderlles, mentres tenta acomodar todos os casos de uso para desenvolvedores, é moi difícil. Vexamos como as diferentes ferramentas intentan e conseguen facelo:
A puntuación de divulgación responsable reflicte a miña opinión persoal: creo que é importante que os vendedores de software sexan receptivos aos problemas de seguridade que se lles denuncian, sexan honestos e transparentes sobre as vulnerabilidades, para garantir que as persoas que usan os seus produtos estean debidamente informadas para tomar decisións sobre a actualización. Isto inclúe a información principal de que unha actualización ten cambios relevantes para a seguridade, abre un CVE para rastrexar e comunicarse sobre o problema e potencialmente notificar aos seus clientes. Creo que é especialmente razoable asumir se o produto trata de CVE, proporcionando información sobre vulnerabilidades no software. Tamén me tranquiliza a resposta rápida, os tempos de corrección razoables e a comunicación aberta coa persoa que denuncia o ataque.
En FOSSA, Snyk e WhiteSource, a vulnerabilidade estaba relacionada con chamada a un xestor de paquetes externo para determinar as dependencias e permitirche organizar a execución do teu código especificando os comandos táctiles e do sistema nos ficheiros gradlew e Podfile.
En Snyk e WhiteSource tamén atoparon unha vulnerabilidade asociada aos comandos do sistema de lanzamento organización que analizou Dockerfile (por exemplo, en Snyk mediante Dockefile podería substituír a utilidade ls (/ bin / ls), causada polo escáner e en WhiteSurce podería substituír o código a través dos argumentos en forma de "eco"; toque / tmp / hacked_whitesource_pip; = 1.0 '«).
En Anchore, a vulnerabilidade foi causada polo uso da utilidade skopeo para traballar con imaxes docker. A operación reduciuse a engadir parámetros da forma '»os»: «$ (toque hacked_anchore)»' ao ficheiro manifest.json, que se substitúen ao chamar a skopeo sen un escape adecuado (só se eliminaron os caracteres «; & < > ", Pero a construción" $ () ").
O mesmo autor realizou un estudo sobre a eficacia da detección de vulnerabilidades non remendado a través de escáneres de seguridade de contedores estibadores e o nivel de falsos positivos.
Ademais do autor defende que varias destas ferramentas use directamente os xestores de paquetes para resolver dependencias. Isto fainos especialmente difíciles de defender. Algúns xestores de dependencias teñen ficheiros de configuración que permiten a inclusión de código de shell.
Aínda que dalgunha maneira se manexen estas formas sinxelas, chamar a estes xestores de paquetes significa inevitablemente gastar cartos. Isto, por dicilo suavemente, non facilita a defensa da aplicación.
Resultados da proba de 73 imaxes que conteñen vulnerabilidades coñecido, así como unha avaliación da eficacia para determinar a presenza de aplicacións típicas en imaxes (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), pódese consultar dentro da publicación feita Na seguinte ligazón.
Sexa o primeiro en opinar sobre