feat(exploit/abuse_unpriv_userns.go): exploit of CVE-2022-0492

[kmahyyg]

co-operate with PR #40.

Use reexec technique to let a multi-thread program (such as this golang program) runs in a different new namespace.

Why reexec?

unshare() is not possible to use safely in multi-thread program, especially current circumstance. Check comments in code for more details.

Signed-off-by: kmahyyg 16604643+kmahyyg@users.noreply.github.com

[kmahyyg]

[kmahyyg]

Please use affected kernel version.

Advisory by Canonical: https://ubuntu.com/security/CVE-2022-0492

Test environment:

Dockerfile:

FROM ubuntu:21.04
LABEL MAINTAINER kmahyyg<16604643+kmahyyg@users.noreply.github.com>

RUN echo "nameserver 223.5.5.5" > /etc/resolv.conf
RUN sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list && \
    apt update -y && \
    apt install -y ca-certificates wget curl nano socat libcap2-bin && \
    rm -rf /var/cache/apt

CMD ["/bin/bash", "-c", "sleep 9999"]

Run:

#!/bin/bash

sysctl -w kernel.unprivileged_userns_clone=1
setenforce 0
cnt1=$(docker run -d --rm -v $(pwd)/cdkbin:/cdkbin --security-opt "seccomp=unconfined" --security-opt "apparmor=unconfined" cve-2022-0492:latest)
echo $cnt1
echo "Container created. Try Exec."
docker exec -it $cnt1 bash

[kmahyyg]

Wiki Content Below:

---

title: Exploit: abuse-unpriv-userns

Exploit: Abuse Unprivileged User Namespace Creation

描述 Description

利用 CVE-2022-0492 进行自动化逃逸。

由于多数发行版默认允许未授权用户创建 User Namespace，可利用此漏洞根据 User Namespace 的 Linux Capabilities 继承规则，当进程创建新的 User Namespace 时，若新 Namespace 下的进程 EUID 和 父 User Namespace 的 EUID 相同，则拥有所有 Linux Capabilities，进而新 Namespace 下进程拥有 CAP_SYS_ADMIN，可在没有 LSM 或 seccomp 的情况下调用 Mount syscall，挂载一个 root cgroup（因为仅有 root cgroup 才存在 release_agent 可供利用），后续利用同 Exploit: mount cgroup 。

When a user namespace is created, the kernel records the effective user ID of the creating process as being the "owner" of the namespace. A process whose effective user ID matches that of the owner of a user namespace and which is a member of the parent namespace has all capabilities in the namespace. By virtue of the previous rule, those capabilities propagate down into all descendant namespaces as well. This means that after creation of a new user namespace, other processes owned by the same user in the parent namespace have all capabilities in the new namespace.

We abuse the capabilities inheritance rules above (which is CVE-2022-0492) to automatically create a new user namespace via an unprivileged user (which is able to do and default for most modern distros, or if you set kernel.unprivileged_userns_clone=1 ), then new processes which is under the same EUID as the parent one who create new namespace has CAP_SYS_ADMIN. Without limitation of LSM(e.g. AppArmor/SELinux) and seccomp, you can mount a root cgroup, then abuse its release_agent feature to escape.

See Also:

• https://ubuntu.com/security/CVE-2022-0492
• https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/
• https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/

用法 Usage

./cdk run abuse-unpriv-userns "<shell-cmd>"
# after exploit, the target host will execute user-specified commands in <shell-cmd> arg.

测试案例 Example

警告⚠️ 请在隔离的实验环境下测试！ YOU'VE BEEN WARNED THIS EXAMPLE CAN ONLY BE RUN IN STRICTLY ISOLATED LAB ENVIRONMENT.

在使用受影响的内核版本的系统下执行下列命令：

Execute command on host who is running vulnerable kernel:

sysctl -w kernel.unprivileged_userns_clone=1
setenforce 0

使用下列 DockerFile 或任意常规镜像启动容器，注意关闭 SELinux 和 Seccomp：

Use the following DockerFile or any frequently-used Image to boot a container, disable SELinux and Seccomp:

DockerFile:

FROM ubuntu:21.04
LABEL MAINTAINER kmahyyg<16604643+kmahyyg@users.noreply.github.com>

RUN echo "nameserver 223.5.5.5" > /etc/resolv.conf
RUN sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list && \
    apt update -y && \
    apt install -y ca-certificates wget curl nano strace ltrace socat libcap2-bin && \
    rm -rf /var/cache/apt

CMD ["/bin/bash", "-c", "sleep 9999"]

使用下列附加参数启动容器并接入 Shell：

Use the following extended params to boot a new container and get a shell inside:

--security-opt "seccomp=unconfined" --security-opt "apparmor=unconfined"

容器内部运行 CDK 工具，

Run CDK inside the container:

./cdk run abuse-unpriv-userns "touch /root/hacked"

看到宿主机存在 /root/hacked 即为攻击成功，攻击者可在宿主机执行任意命令。

When you see /root/hacked on host, which means exploit successfully, you could execute any command on host as you wanted.

[kmahyyg]

Binary:

cdk-linux-amd64-ec87334-test.zip

[neargle]

Awesome! But the cve number is wrong, I think you mean CVE-2022-0492. In my cognition, cve-2022-0492: not only RDMA is available for exploit, misc maybe also.
Anyway, the code is nice~

[kmahyyg]

Awesome! But the cve number is wrong, I think you mean CVE-2022-0492. In my cognition, cve-2022-0492: not only RDMA is available for exploit, misc maybe also. Anyway, the code is nice~

Sorry, the CVE number in wiki thread is fixed also PR title.

[kmahyyg]

Please do not merge it until I test misc controller. I just googled that:

The Linux 5.13 development kernel is introducing a new "misc" cgroup controller. The misc cgroup controller is to be used for resources that are controlled by simply counting / limiting the number of resource instances in a scalar manner.

My testing environment runs Linux 5.4 (Ubuntu 20.04). I will test it on my Arch Linux.

[neargle]

Please do not merge it until I test misc controller. I just googled that:

The Linux 5.13 development kernel is introducing a new "misc" cgroup controller. The misc cgroup controller is to be used for resources that are controlled by simply counting / limiting the number of resource instances in a scalar manner.

My testing environment runs Linux 5.4 (Ubuntu 20.04). I will test it on my Arch Linux.

OK o(￣▽￣)👍

[kmahyyg]

Well, on newer kernel, the only available cgroup for exploit seems to be misc instead of rdma.

[neargle]

Well, on newer kernel, the only available cgroup for exploit seems to be misc instead of rdma.

Maybe we can check it before exploit.

[kmahyyg]

Well, on newer kernel, the only available cgroup for exploit seems to be `misc` instead of `rdma`.

Maybe we can check it before exploit.

Good idea. I will deprecate half code I wrote now, which detect kernel version instead of this.

[kmahyyg]

Test:

Robustness of validating user input:

Auto detection of available cgroup:

Detect misc:

Detect rdma:

mount-cgroup working:

mount-cgroup blkio with privileged container working:

[kmahyyg]

Please check and merge. Thanks.

[kmahyyg]

Binary:
cdk-linux-amd64-ea0ba83-test.zip