GHSA-2r4r-5x78-mvqf

Описание

Summary

_Short summary of the problem. Make the impact and severity as clear as possible.

It is possible to trick the virt-handler component into changing the ownership of arbitrary files on the host node to the unprivileged user with UID 107 due to mishandling of symlinks when determining the root mount of a virt-launcher pod.

Details

Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

In the current implementation, the virt-handler does not verify whether the launcher-sock is a symlink or a regular file. This oversight can be exploited, for example, to change the ownership of arbitrary files on the host node to the unprivileged user with UID 107 (the same user used by virt-launcher) thus, compromising the CIA (Confidentiality, Integrity and Availability) of data on the host. To successfully exploit this vulnerability, an attacker should be in control of the file system of the virt-launcher pod.

PoC

Complete instructions, including specific configuration details, to reproduce the vulnerability.

In this demonstration, two additional vulnerabilities are combined with the primary issue to arbitrarily change the ownership of a file located on the host node:

1. A symbolic link (launcher-sock) is used to manipulate the interpretation of the root mount within the affected container, effectively bypassing expected isolation boundaries.
2. Another symbolic link (disk.img) is employed to alter the perceived location of data within a PVC, redirecting it to a file owned by root on the host filesystem.
3. As a result, the ownership of an existing host file owned by root is changed to a less privileged user with UID 107.

It is assumed that an attacker has access to a virt-launcher pod's file system (for example, obtained using another vulnerability) and also has access to the host file system with the privileges of the qemu user (UID=107). It is also assumed that they can create unprivileged user namespaces:

The below is inspired by an article, where the attacker constructs an isolated environment solely using Linux namespaces and an augmented Alpine container root file system.

After the environment is set, the launcher-sock in the virt-launcher container should be replaced with a symlink to ../../../../../../../../../proc/2245509/root/tmp/bad.sock (2245509 is the PID of the above isolated shell process). This should be done, however, in a the right moment. For this demonstration, it was decided to trigger the bug while leveraging a race condition when creating or updating a VMI:

The manifest of the #acr("vmi") which is going to trigger the bug is:

Just before the line is executed, the attacker should replace the launcher-sock with a symlink to the bad.sock controlled by the isolated process:

Upon successful exploitation, virt-launcher connects to the attacker controlled socket, misinterprets the root mount and changes the permissions of the host's /etc/passwd file:

The attacker controlling an unprivileged user can now update the contents of the file.

Impact

What kind of vulnerability is it? Who is impacted?

This oversight can be exploited, for example, to change the ownership of arbitrary files on the host node to the unprivileged user with UID 107 (the same user used by virt-launcher) thus, compromising the CIA (Confidentiality, Integrity and Availability) of data on the host.