CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 1CVE-2019-11245 – kubelet-started container uid changes to root after first restart or if image is already pulled to the node
https://notcve.org/view.php?id=CVE-2019-11245
In kubelet v1.13.6 and v1.14.2, containers for pods that do not specify an explicit runAsUser attempt to run as uid 0 (root) on container restart, or if the image was previously pulled to the node. If the pod specified mustRunAsNonRoot: true, the kubelet will refuse to start the container as root. If the pod did not specify mustRunAsNonRoot: true, the kubelet will run the container as uid 0. En kubelet v1.13.6 y v1.14.2, los contenedores para pods que no especifican un intento runAsUser explícito de ejecutarse como uid 0 (raíz) en el reinicio del contenedor, o si la imagen se extrajo previamente en el nodo. Si el pod especificado mustRunAsNonRoot: true, el kubelet se negará a iniciar el contenedor como root. • https://github.com/kubernetes/kubernetes/issues/78308 https://security.netapp.com/advisory/ntap-20190919-0003 • CWE-264: Permissions, Privileges, and Access Controls CWE-703: Improper Check or Handling of Exceptional Conditions •
CVSS: 8.1EPSS: 0%CPEs: 8EXPL: 0CVE-2019-11247 – Kubernetes kube-apiserver allows access to custom resources via wrong scope
https://notcve.org/view.php?id=CVE-2019-11247
The Kubernetes kube-apiserver mistakenly allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced. Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges). Kubernetes affected versions include versions prior to 1.13.9, versions prior to 1.14.5, versions prior to 1.15.2, and versions 1.7, 1.8, 1.9, 1.10, 1.11, 1.12. El kube-apiserver de Kubernetes permite por error el acceso a un recurso personalizado de ámbito de clúster si la solicitud se realiza como si el recurso estuviera con espacio de nombres. Las autorizaciones para el recurso al que se tiene acceso de esta manera se aplican mediante roles y enlaces de roles dentro del espacio de nombres, lo que significa que un usuario con acceso solo a un recurso en un espacio de nombres podría crear, ver actualizar o eliminar el recurso de ámbito de clúster (según sus privilegios de rol de espacio de nombres). • https://access.redhat.com/errata/RHBA-2019:2816 https://access.redhat.com/errata/RHBA-2019:2824 https://access.redhat.com/errata/RHSA-2019:2690 https://access.redhat.com/errata/RHSA-2019:2769 https://github.com/kubernetes/kubernetes/issues/80983 https://groups.google.com/d/msg/kubernetes-security-announce/vUtEcSEY6SM/v2ZZxsmtFQAJ https://security.netapp.com/advisory/ntap-20190919-0003 https://access.redhat.com/security/cve/CVE-2019-11247 https://bugzilla.redhat.com/show_bug.cgi?id=1 • CWE-20: Improper Input Validation CWE-284: Improper Access Control CWE-863: Incorrect Authorization •
CVSS: 6.5EPSS: 0%CPEs: 5EXPL: 0CVE-2019-11246 – kubectl cp allows symlink directory traversal
https://notcve.org/view.php?id=CVE-2019-11246
The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine. If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path on the user’s machine when kubectl cp is called, limited only by the system permissions of the local user. Kubernetes affected versions include versions prior to 1.12.9, versions prior to 1.13.6, versions prior to 1.14.2, and versions 1.1, 1.2, 1.4, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11. • https://github.com/kubernetes/kubernetes/pull/76788 https://groups.google.com/forum/#%21topic/kubernetes-security-announce/NLs2TGbfPdo https://security.netapp.com/advisory/ntap-20190919-0003 https://access.redhat.com/security/cve/CVE-2019-11246 https://bugzilla.redhat.com/show_bug.cgi?id=1721704 • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') CWE-59: Improper Link Resolution Before File Access ('Link Following') CWE-61: UNIX Symbolic Link (Symlink) Following •
CVSS: 5.0EPSS: 0%CPEs: 4EXPL: 0CVE-2019-11244 – kubectl creates world-writeable cached schema files
https://notcve.org/view.php?id=CVE-2019-11244
In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation. En Kubernetes versión 1.8.x hasta versión 1.14.x, el componente kubectl almacena en caché la información del esquema en la ubicación especificada por --cache-dir (defaulting to $HOME/.kube/http-cache), escrita con permisos world-writeable (rw-rw-rw-). Si se especifica --cache-dir y se apunta a una ubicación distinta accesible para otros usuarios o grupos, los archivos escritos pueden ser modificados por otros usuarios o grupos e interrumpir la invocación de Kubectl. A flaw was found in kubectl that leaves http-cache files with read/write permissions for any user. • http://www.securityfocus.com/bid/108064 https://access.redhat.com/errata/RHSA-2019:3942 https://access.redhat.com/errata/RHSA-2020:0020 https://access.redhat.com/errata/RHSA-2020:0074 https://github.com/kubernetes/kubernetes/issues/76676 https://security.netapp.com/advisory/ntap-20190509-0002 https://access.redhat.com/security/cve/CVE-2019-11244 https://bugzilla.redhat.com/show_bug.cgi?id=1703209 • CWE-524: Use of Cache Containing Sensitive Information CWE-732: Incorrect Permission Assignment for Critical Resource •