A flaw was found in the Openshift console. The /API/helm/verify endpoint is tasked to fetch and verify the installation of a Helm chart from a URI that is remote HTTP/HTTPS or local. Access to this endpoint is gated by the authHandlerWithUser() middleware function. Contrary to its name, this middleware function does not verify the validity of the user's credentials. As a result, unauthenticated users can access this endpoint.
Description An ExecSync request runs a command in a container and returns the output to the Kubelet. It is used for readiness and liveness probes within a pod. The way CRI-O runs ExecSync commands is through conmon. CRI-O asks conmon to start the process, and conmon writes the output to disk. CRI-O then reads the output and returns it to the Kubelet.
If the output of the command is large enough, it is possible to exhaust the memory (or disk usage) of the node. The following deployment is an example yaml file that will output around 8GB of ‘A’ characters, which would be written to disk by conmon and read by CRI-O.
yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment100 spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 lifecycle: postStart: exec: command: ["/bin/sh", "-c", "seq 1 50000000; do echo -n 'aaaaaaaaaaaaaaaa'; done"]
Impact It is possible for the node to be exhausted of memory or disk space, depending on the node the command is being run on. What is further problematic is that the memory and disk usage aren't attributed to the container, as this file and its processing are implementation details of CRI-O. The consequence of the exhaustion is that other services on the node, e.g. other containers, will be unable to allocate memory and thus causing a denial of service.
Patches This vulnerability will be fixed in 1.24.1, 1.23.3, 1.22.5, v1.21.8, v1.20.8, v1.19.7
Workarounds At the time of writing, no workaround exists other than ensuring only trusted images are used.
References https://github.com/containerd/containerd/security/advisories/GHSA-5ffw-gxpp-mxpf
For more information If you have any questions or comments about this advisory: Open an issue in the CRI-O repo To make a report, email your vulnerability to the private cncf-crio-security@lists.cncf.io list with the security details and the details expected for all CRI-O bug reports.
Credits Disclosed by Ada Logics in a security audit sponsored by CNCF and facilitated by OSTIF.
A flaw was found in the way haproxy processed certain HTTP/2 request packets. An attacker could send crafted HTTP/2 request packets which cause memory corruption, leading to a crash or potential remote arbitrary code execution with the permissions of the user running haproxy.
An incorrect handling of the supplementary groups in the Podman container engine might lead to the sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.
Heketi is used to manage GlusterFS nodes and volumes. The default configuration of Heketi does not require any authentication potentially exposing the management interface to misuse.
Withdrawn Advisory
This advisory has been withdrawn because the vulnerability does not affect a package in one of the GitHub Advisory Database's supported ecosystems. This link is maintained to preserve external references.
Original Description
A flaw was found in the /oauth/token/request custom endpoint of the OpenShift OAuth server allowing for XSS generation of CLI tokens due to missing X-Frame-Options and CSRF protections. If not otherwise prevented, a separate XSS vulnerability via JavaScript could further allow for the extraction of these tokens.
Withdrawn Advisory This advisory has been withdrawn because the vulnerability does not apply to the Prometheus golang package. This link is maintained to preserve external references.
Original Description A stored, DOM based, cross-site scripting (XSS) flaw was found in Prometheus before version 2.7.1. An attacker could exploit this by convincing an authenticated user to visit a crafted URL on a Prometheus server, allowing for the execution and persistent storage of arbitrary scripts.
The kube-rbac-proxy container before version 0.4.1 as used in Red Hat OpenShift Container Platform does not honor TLS configurations, allowing for use of insecure ciphers and TLS 1.0. An attacker could target traffic sent over a TLS connection with a weak configuration and potentially break the encryption.
A memory leak was discovered in the backport of fixes for CVE-2018-16864 in Red Hat Enterprise Linux (since version v219-62.2) and CentOS. Function dispatchmessagereal() in journald-server.c does not free the memory allocated by setiovecfieldfree() to store the CMDLINE= entry. A local attacker may use this flaw to make systemd-journald crash.
However systemd-journald crash is automatically restarted by systemd by default.
A security issue has been found in the kubernetes-csi external-provisioner, external-snapshotter, and external-resizer sidecars that impacts most versions of the sidecars bundled in Container Storage Interface (CSI) drivers. The vulnerabilities are medium severity and can result in unauthorized volume data access or mutation when using CSI volume snapshot, cloning or resizing features in Kubernetes. Upgrading your CSI drivers to the fixed sidecars is recommended.
Upstream Issue:
https://github.com/kubernetes/kubernetes/issues/85233
External Reference:
https://groups.google.com/forum/#!topic/kubernetes-security-announce/aXiYN0q4uIw
The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes creates a tar inside the container, 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. The untar function can both create and follow symbolic links. The issue is resolved in kubectl v1.11.9, v1.12.7, v1.13.5, and v1.14.0.
A third issue was discovered with the Kubernetes kubectl cp command that could enable a directory traversal such that a malicious container could replace or create files on a user’s workstation. The vulnerability is a client-side defect and requires user interaction to be exploited.
This vulnerability allows a malicious container to cause a file to be created or replaced on the client computer when the client uses the kubectl cp operation. The vulnerability is a client-side defect and requires user interaction to be exploited.
Upstream Issue:
https://github.com/kubernetes/kubernetes/issues/80984
External References:
https://groups.google.com/forum/#!topic/kubernetes-security-discuss/Vf31dXp0EJc
In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.
A data modification vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in User.java, IdStrategy.java that allows attackers to submit crafted user names that can cause an improper migration of user record storage formats, potentially preventing the victim from logging into Jenkins.
An information exposure vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in DirectoryBrowserSupport.java that allows attackers with the ability to control build output to browse the file system on agents running builds beyond the duration of the build using the workspace browser.
A sandbox bypass vulnerability exists in Script Security Plugin 1.47 and earlier in groovy-sandbox/src/main/java/org/kohsuke/groovy/sandbox/SandboxTransformer.java that allows attackers with Job/Configure permission to execute arbitrary code on the Jenkins master JVM, if plugins using the Groovy sandbox are installed.
A sandbox bypass vulnerability exists in Pipeline: Groovy Plugin 2.59 and earlier in groovy-sandbox/src/main/java/org/kohsuke/groovy/sandbox/SandboxTransformer.java, groovy-cps/lib/src/main/java/com/cloudbees/groovy/cps/SandboxCpsTransformer.java that allows attackers with Job/Configure permission, or unauthorized attackers with SCM commit privileges and corresponding pipelines based on Jenkinsfiles set up in Jenkins, to execute arbitrary code on the Jenkins master JVM
A denial of service vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in CronTab.java that allows attackers with Overall/Read permission to have a request handling thread enter an infinite loop.
A use-after-free flaw can occur in the Linux kernel due to a race condition between packetdobind() and packetnotifier() functions called for an AFPACKET socket. An unprivileged local user could use this flaw to induce kernel memory corruption on the system, leading to an unresponsive system or to a crash. Due to the nature of the flaw, privilege escalation cannot be fully ruled out.
External Reference:
https://blogs.securiteam.com/index.php/archives/3731
A probable fix:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=15fe076edea787807a7cdc168df832544b58eba6
Kibana versions before 6.4.3 and 5.6.13 contain an arbitrary file inclusion flaw in the Console plugin. An attacker with access to the Kibana Console API could send a request that will attempt to execute javascript code. This could possibly lead to an attacker executing arbitrary commands with permissions of the Kibana process on the host system.
A out of bound write can occur when patching a Openshift object using the 'oc patch' functionality in OpenShift Container Platform 3.6 and earlier. An attacker can use this flaw to cause a denial of service attack on the Openshift master api service which provides cluster management.
A cross site scripting flaw exists in the tetonic-console component of Openshift Container Platform 3.11. An attacker with the ability to create pods can use this flaw to perform actions on the K8s API as the victim.
Kibana versions 5.3.0 to 6.4.1 had a cross-site scripting (XSS) vulnerability via the source field formatter that could allow an attacker to obtain sensitive information from or perform destructive actions on behalf of other Kibana users.
Users who cached their CLI authentication before Jenkins was updated to 2.150.2 and newer, or 2.160 and newer, would remain authenticated in Jenkins 2.171 and earlier and Jenkins LTS 2.164.1 and earlier, because the fix for CVE-2019-1003004 in these releases did not reject existing remoting-based CLI authentication caches.
A sandbox bypass vulnerability in Jenkins Pipeline: Groovy Plugin 2.64 and earlier allows attackers to invoke arbitrary constructors in sandboxed scripts.
The f:validateButton form control for the Jenkins UI did not properly escape job URLs in Jenkins 2.171 and earlier and Jenkins LTS 2.164.1 and earlier, resulting in a cross-site scripting (XSS) vulnerability exploitable by users with the ability to control job names.
A sandbox bypass vulnerability in Jenkins Script Security Plugin 1.55 and earlier allows attackers to invoke arbitrary constructors in sandboxed scripts.
A sandbox bypass vulnerability exists in Jenkins Job DSL Plugin 1.71 and earlier in job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/AbstractDslScriptLoader.groovy, job-dsl-plugin/build.gradle, job-dsl-plugin/src/main/groovy/javaposse/jobdsl/plugin/JobDslWhitelist.groovy, job-dsl-plugin/src/main/groovy/javaposse/jobdsl/plugin/SandboxDslScriptLoader.groovy that allows attackers with control over Job DSL definitions to execute arbitrary code on the Jenkins master JVM.
A denial of service vulnerability was found in the Kubernetes API server. A remote user, with authorization to apply patches, could exploit this via crafted JSON input, causing excessive consumption of resources and subsequent denial of service.
A sandbox bypass vulnerability exists in Jenkins Script Security Plugin 1.52 and earlier in RejectASTTransformsCustomizer.java that allows attackers with Overall/Read permission to provide a Groovy script to an HTTP endpoint that can result in arbitrary code execution on the Jenkins master JVM.