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 sandbox bypass vulnerability exists in Jenkins Matrix Project Plugin 1.13 and earlier in pom.xml, src/main/java/hudson/matrix/FilterScript.java that allows attackers with Job/Configure permission to execute arbitrary code on the Jenkins master JVM.

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 flaw was found in ghostscript, versions 9.x before 9.50, in the setsystemparams procedure where it did not properly secure its privileged calls, enabling scripts to bypass -dSAFER restrictions. A specially crafted PostScript file could disable security protection and then have access to the file system, or execute arbitrary commands.

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.

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 in Jenkins Pipeline: Groovy Plugin 2.64 and earlier allows attackers to invoke arbitrary constructors in sandboxed scripts.

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 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.

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.

A sandbox bypass vulnerability exists in Script Security Plugin 1.49 and earlier in src/main/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/GroovySandbox.java that allows attackers with the ability to provide sandboxed scripts to execute arbitrary code on the Jenkins master JVM.

A sandbox bypass vulnerability exists in Pipeline: Groovy Plugin 2.61 and earlier in src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowDefinition.java, src/main/java/org/jenkinsci/plugins/workflow/cps/CpsGroovyShellFactory.java that allows attackers with Overall/Read permission to provide a pipeline script to an HTTP endpoint that can result in arbitrary code execution on the Jenkins master JVM.

A sandbox bypass vulnerability exists in Pipeline: Declarative Plugin 1.3.3 and earlier in pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/Converter.groovy that allows attackers with Overall/Read permission to provide a pipeline script to an HTTP endpoint that can result in arbitrary code execution on the Jenkins master JVM.

A flaw was found during the upgrade of an existing OpenShift Container Platform 3.x cluster. Using CRI-O, the dockergc service account is assigned to the current namespace of the user performing the upgrade. This flaw can allow an unprivileged user to escalate their privileges to those allowed by the privileged Security Context Constraints.

Jenkins 2.191 and earlier, LTS 2.176.2 and earlier allowed users to obtain CSRF tokens without an associated web session ID, resulting in CSRF tokens that did not expire and could be used to bypass CSRF protection for the anonymous user.

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 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.

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

An information exposure and denial of service vulnerability exists in Jenkins Token Macro Plugin 2.5 and earlier in src/main/java/org/jenkinsci/plugins/tokenmacro/Parser.java, src/main/java/org/jenkinsci/plugins/tokenmacro/TokenMacro.java, src/main/java/org/jenkinsci/plugins/tokenmacro/impl/AbstractChangesSinceMacro.java, src/main/java/org/jenkinsci/plugins/tokenmacro/impl/ChangesSinceLastBuildMacro.java, src/main/java/org/jenkinsci/plugins/tokenmacro/impl/ProjectUrlMacro.java that allows attackers with the ability to control token macro input (such as SCM changelogs) to define recursive input that results in unexpected macro evaluation.

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.

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, ghostscript versions prior to 9.50, in the .pdfhookDSCCreator procedure where it did not properly secure its privileged calls, enabling scripts to bypass -dSAFER restrictions. A specially crafted PostScript file could disable security protection and then have access to the file system, or execute arbitrary commands.

A flaw was found in, ghostscript versions prior to 9.50, in the .pdfexectoken and other procedures where it did not properly secure its privileged calls, enabling scripts to bypass -dSAFER restrictions. A specially crafted PostScript file could disable security protection and then have access to the file system, or execute arbitrary commands.

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.

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.

Kibana versions before 6.8.9 and 7.7.0 contain a prototype pollution flaw in TSVB. An authenticated attacker with privileges to create TSVB visualizations could insert data that would cause Kibana to execute arbitrary code. This could possibly lead to an attacker executing code with the permissions of the Kibana process on the host system.

An improper authorization vulnerability exists in Jenkins 2.158 and earlier, LTS 2.150.1 and earlier in core/src/main/java/hudson/security/TokenBasedRememberMeServices2.java that allows attackers with Overall/RunScripts permission to craft Remember Me cookies that would never expire, allowing e.g. to persist access to temporarily compromised user accounts.

An improper authorization vulnerability exists in Jenkins 2.158 and earlier, LTS 2.150.1 and earlier in core/src/main/java/hudson/security/AuthenticationProcessingFilter2.java that allows attackers to extend the duration of active HTTP sessions indefinitely even though the user account may have been deleted in the mean time.

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.