The flaw, tracked as CVE-2022-0778, was reported to the OpenSSL Project by Google vulnerability researcher Tavis Ormandy.

The security hole affects OpenSSL versions 1.0.2, 1.1.1 and 3.0, and it has been fixed with the release of versions 1.0.2zd (for premium support customers), 1.1.1n and 3.0.2. Version 1.1.0 is also impacted, but it’s no longer supported and will not receive a patch.

Exploitation of the vulnerability is possible in certain situations, and it can lead to a DoS attack against a process that parses externally supplied certificates.

“The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli,” the OpenSSL Project explained in its advisory. “Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form.”

“It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters,” the advisory reads.

Source: High-Severity DoS Vulnerability Patched in OpenSSL | SecurityWeek.Com

A vulnerability in the container runtime engine CRI-O can be exploited by a rogue user to gain root-level access on a host.

In a Kubernetes environment powered by CRI-O, the security hole can be used by a miscreant to move through a cluster as an administrator, install malware, and cause other chaos.

CrowdStrike’s threat research team discovered the privilege-escalation flaw in CRI-O version 1.19. The bug, tracked as CVE-2022-0811 and more creatively dubbed cr8escape, received a severity score of 8.8 out of 10.

CrowdStrike privately disclosed the vulnerability, and CRI-O’s developers today released a fix while recommending immediate patching. Besides Kubernetes, other software and platforms that depend on or use CRI-O – these include OpenShift and Oracle Container Engine for Kubernetes – may also be vulnerable, CrowdStrike warned.

Each Kubernetes node includes a container runtime such as CRI-O. Among other tasks, the container runtime allows containerized apps to safely share each node’s underlying Linux kernel and other resources. As part of this, Linux ensures that when one container alters a kernel setting, this change isn’t reflected in other containers or on the host as a whole, thus keeping the containers suitably isolated from each other and the underlying platform, CrowdStrike explained.

“Some parameters are namespaced and can therefore be set in a single container without impacting the system at large,” the threat researchers wrote. “Kubernetes and the container runtimes it drives allow pods to update these ‘safe’ kernel settings while blocking access to others.”

And herein lies the security flaw: CRI-O introduced a bug that allows attackers to bypass these safeguards and set kernel parameters. “Due to the addition of sysctl support in version 1.19, [the pinns utility] will now blindly set any kernel parameters it’s passed without validation,” the threat researchers explained.

This means that anyone who can deploy a pod on a cluster using the CRI-O runtime can “abuse the kernel.core_pattern parameter to achieve container escape and arbitrary code execution as root on any node in the cluster,” CrowdStrike continued.

[…]

Source: Kubernetes container runtime CRI-O has make-me-root flaw