Containerd 1.5.9 has been released to fix CVE-2021-43816 (5th Jan, 2022)

Preface: A Pod represents a single instance of a running process in your cluster. Pods contain one or more containers, such as Docker containers. When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod’s resources.

Background: Containerd was designed to be used by Docker and Kubernetes as well as any other container platform that wants to abstract away syscalls or OS specific functionality to run containers on linux, windows, solaris, or other operation system. Kubernetes is removing support for Docker as a container runtime. Kubernetes does not actually handle the process of running containers on a machine. Instead, it relies on another piece of software called a container runtime. CRI is a containerd plugin implementation of Kubernetes container runtime interface (CRI). With it, you could run Kubernetes using containerd as the container runtime.

Vulnerability details: On installations using SELinux, such as EL8 (CentOS, RHEL), Fedora, or SUSE MicroOS, with containerd since v1.5.0-beta.0 as the backing container runtime interface (CRI), an unprivileged pod scheduled to the node may bind mount, via hostPath volume, any privileged, regular file on disk for complete read/write access (sans delete). Such is achieved by placing the in-container location of the hostPath volume mount at either `/etc/hosts`, `/etc/hostname`, or `/etc/resolv.conf`. These locations are being relabeled indiscriminately to match the container process-label which effectively elevates permissions for savvy containers that would not normally be able to access privileged host files.

Additional: Simple conceptual diagram attached.

Remediation: This issue has been resolved in version 1.5.9. Users are advised to upgrade as soon as possible.

Reference: https://github.com/containerd/containerd/security/advisories/GHSA-mvff-h3cj-wj9c

CVE-2021-22045 – VMware ESXi,VMware Workstation and VMware Fusion contains a heap-overflow vulnerability in CD-ROM device emulation (4th Jan 2022)

Preface: You cannot connect to a virtual machine’s CD/DVD-ROM device with the Administrator role. By default setting, the Administrator role does not have permission to access a virtual machine’s CD/DVD-ROM device.

Background: Most of the files stored on a VMFS volume, though, are large files – virtual disk files, swap files, installation image files. VMFS operates on disks attached to ESXi servers but not on computers running VMware Workstation or VMware Player.VMFS 6 was released in vSphere 6.5 and is used in vSphere 6.7, vSphere 7.0, and newer versions such as vSphere 7.0 Update 3.

Vulnerability details: VMware ESXi (7.0, 6.7 before ESXi670-202111101-SG and 6.5 before ESXi650-202110101-SG), VMware Workstation (16.2.0) and VMware Fusion (12.2.0) contains a heap-overflow vulnerability in CD-ROM device emulation. A malicious actor with access to a virtual machine with CD-ROM device emulation may be able to exploit this vulnerability in conjunction with other issues to execute code on the hypervisor from a virtual machine.

VMware released security advisory for ESXi hosts. Remedy for ESXi 6.5 and 6.7 are ready. However, 7.0 there only provides workaround. For more details, please refer to the link – https://kb.vmware.com/s/article/87249

Official announcement: https://www.vmware.com/security/advisories/VMSA-2022-0001.html

Additional: Because the supplier wants to keep it confidential. So the details have not been announced yet. My observations of this vulnerability are drawn in the attached drawings.

CVE-2021-1918 : Improper handling of resource allocation in virtual machines can lead to information exposure in Snapdragon. NVD Published Date 3rd JAN, 2022

Preface: The specifics vulnerability (CVE-2021-1918) has notified customer on 06/07/2021. But vendor security advisory was released on 6th December, 2022. Finally, US-CERT release the details on 3rd Jan, 2021. As a researcher or end user, it is not an issue.

Background: Snapdragon is a suite of system on a chip (SoC) semiconductor products for mobile devices designed and marketed by Qualcomm Technologies Inc. The Snapdragon’s central processing unit (CPU) uses the ARM architecture. In Snapdragon SoCs, three components are used to provide access control: Virtual Master ID Mapping Table (VMIDMT), External Protection Unit (XPU), and System Memory Management Unit (SMMU). VMIDMT and XPU work together. The SMMU is a hardware component that performs address translation and access control for bus initiators outside of the CPU.

Vulnerability details: Certain versions of Snapdragon Consumer IOT Snapdragon Industrial IOT Snapdragon Mobile from Qualcomm Inc. contain the following vulnerability:
Improper handling of resource allocation in virtual machines can lead to information exposure in Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile.

My observation: Since vendor not providing the technical details. According to Snapdragon design, a well know attack surface will be on SMMU. For the possibilities of cyber attack details, please refer to attached diagram for reference.

Vendor announcement: Additional vulnerability are also released by vendor on December, 2021. Please refer to link for details – https://www.qualcomm.com/company/product-security/bulletins/december-2021-bulletin#_cve-2021-1918

Go programming language design limitation – CVE-2021-44717 (NVD Published Date 1st Jan 2022)

Preface: Golang is useful for carrying out programming for scalable servers and large software systems. The Golang programming language was built to fill in the gaps of C++ and Java that Google came across while working with its servers and distributed systems.

Not limited to Google, well-known cloud businesses such as Dropbox, Terraform, Kubernetes, and Docker also develop applications for the Go programming language.

Go as a language is more similar to C, however in addition to C features, Go offers memory safety, garbage collection, structural typing, and CSP-Style concurrency.

Background: There is a function in syscall package, func ForkExec(argv0 string, argv []string, attr *ProcAttr) (pid int, err error) that forks and execs a given process with given arguments and additional ProcAttr in which you can define environment and open files. It handles most of the stuff, even the user/group namespaces.

Vulnerability details: There’s a flaw in golang’s syscall.ForkExec() interface. An attacker who manages to first cause a file descriptor exhaustion for the process, then cause syscall[.]ForkExec() to be called repeatedly, could compromise data integrity and/or confidentiality in a somewhat uncontrolled way in programs linked with and using syscall[.]ForkExec().

Reference: Fedora has released a security update for golang to fix the vulnerabilities (Affected OS:Fedora 35) – https://bodhi.fedoraproject.org/updates/FEDORA-2021-29943703de