Compartir comentarios
Las respuestas se generan en base a la documentación.

No eventos de seguridad de Docker

Esta página enumera las vulnerabilidades de seguridad que Docker mitigó, de tal manera que los procesos ejecutados en contenedores de Docker nunca fueron vulnerables al fallo, incluso antes de que se solucionara. Esto asume que los contenedores se ejecutan sin añadir capacidades adicionales o no se ejecutan como --privileged.

La lista a continuación no está ni de lejos completa. Más bien, es una muestra de los pocos fallos que se ha observado que han atraído revisiones de seguridad y vulnerabilidades divulgadas públicamente. Con toda probabilidad, los fallos que no han sido reportados superan con creces a los que sí. Por suerte, dado que el enfoque de Docker es seguro por defecto mediante apparmor, seccomp y la eliminación de capacidades, es probable que mitigue los fallos desconocidos tan bien como lo hace con los conocidos.

Errores mitigados:

  • CVE-2013-1956, 1957, 1958, 1959, 1979, CVE-2014-4014, 5206, 5207, 7970, 7975, CVE-2015-2925, 8543, CVE-2016-3134, 3135, etc.: La introducción de espacios de nombres de usuario sin privilegios provocó un gran aumento en la superficie de ataque disponible para los usuarios sin privilegios al otorgarles acceso legítimo a llamadas al sistema que antes eran exclusivas de root, como mount(). Todos estos CVE son ejemplos de vulnerabilidades de seguridad debido a la introducción de espacios de nombres de usuario. Docker puede usar espacios de nombres de usuario para configurar contenedores, pero luego no permite que el proceso dentro del contenedor cree sus propios espacios de nombres anidados a través del perfil seccomp predeterminado, lo que hace que estas vulnerabilidades no sean explotables.
  • CVE-2014-0181, CVE-2015-3339: Estos son fallos que requieren la presencia de un binario setuid. Docker deshabilita los binarios setuid dentro de los contenedores a través de la bandera de proceso NO_NEW_PRIVS y otros mecanismos.
  • CVE-2014-4699: Un fallo en ptrace() podría permitir la escalada de privilegios. Docker deshabilita ptrace() dentro del contenedor usando apparmor, seccomp y eliminando CAP_PTRACE. ¡Tres niveles de protección allí!
  • CVE-2014-9529: Una serie de llamadas a keyctl() diseñadas podría causar DoS del kernel o corrupción de memoria. Docker deshabilita keyctl() dentro de los contenedores usando seccomp.
  • CVE-2015-3214, 4036: Estos son fallos en controladores de virtualización comunes que podrían permitir a un usuario del sistema operativo invitado ejecutar código en el sistema operativo anfitrión. Explotarlos requiere acceso a los dispositivos de virtualización en el invitado. Docker oculta el acceso directo a estos dispositivos cuando se ejecuta sin --privileged. Curiosamente, estos parecen ser casos en los que los contenedores son "más seguros" que una máquina virtual, yendo en contra de la creencia común de que las máquinas virtuales son "más seguras" que los contenedores.
  • CVE-2016-0728: Un uso después de la liberación (use-after-free) causado por llamadas a keyctl() diseñadas podría llevar a una escalada de privilegios. Docker deshabilita keyctl() dentro de los contenedores usando el perfil seccomp predeterminado.
  • CVE-2016-2383: Un fallo en eBPF (el DSL especial dentro del kernel utilizado para expresar cosas como filtros seccomp) permitía lecturas arbitrarias de la memoria del kernel. La llamada al sistema bpf() está bloqueada dentro de los contenedores de Docker usando (irónicamente) seccomp.
  • CVE-2016-3134, 4997, 4998: Un fallo en setsockopt con IPT_SO_SET_REPLACE, ARPT_SO_SET_REPLACE y ARPT_SO_SET_REPLACE que causa corrupción de memoria o escalada de privilegios local. Estos argumentos están bloqueados por CAP_NET_ADMIN, que Docker no permite por defecto.

Errores no mitigados:

  • CVE-2015-3290, 5157: Fallos en el manejo de interrupciones no enmascarables del kernel permitían la escalada de privilegios. Se pueden explotar en contenedores de Docker porque la llamada al sistema modify_ldt() no está bloqueada usando seccomp.
  • CVE-2016-5195: Se encontró una condición de carrera en la forma en que el subsistema de memoria del kernel de Linux manejaba la rotura de copia en escritura (COW) de asignaciones de memoria privada de solo lectura, lo que permitía a usuarios locales sin privilegios obtener acceso de escritura a la memoria de solo lectura. También conocido como "dirty COW". Mitigaciones parciales: en algunos sistemas operativos esta vulnerabilidad se mitiga mediante la combinación del filtrado seccomp de ptrace y el hecho de que /proc/self/mem sea de solo lectura.