This POC won't work for me about cve-2019-5736-poc

[gm12367]

I have tested on RHEL7.5 and CentOS7.5 but got the same result, I disabled SELinux already, but the exploit didn't work. I will test again with Ubuntu 16.04 and 18.04 LTS again tommorow, any futher update I will address here.

[mikaelkall]

Hi, just to add some information if it can be of interest, I had the same problem with libapparmor.so.1 on Ubuntu 16.04 and it was not straightforward to fix the issue and at the same time avoid to patch the issue. However I can confirm the PoC works fine on ubuntu-18-04. Here is my working Vagrantfile if anyone want to replicate my working environment.

# -*- mode: ruby -*-
# vi: set ft=ruby :

$provision = <<-SCRIPT
apt-get -y update
apt-get -y install curl
curl -fsSL test.docker.com -o test-docker.sh
VERSION=18.03.1 sh test-docker.sh
SCRIPT

Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-18.04"
  config.vm.provision "shell", inline: $provision
end

[Frichetten]

That's really interesting, what host OS are you using/version of Docker are you using? I had not seen another PID that had "runc" in the cmdline.

That "libseccomp" error is expected. It doesn't indicate the exploit didn't work.

Did you check if a file was created in the hosts /tmp/ directory?

[gm12367]

About the first question, I fixed myself, because I named my script as "runc-test.sh" so everytime I execute it then it will be a pid name contain this script name, "runc" pid disappear after I rename this bash script.

So I execute your POC again, but I just got "[+] Overwritten /bin/sh successfully" output even after I attach in docker with /bin/sh. No /tmp/shadow folder created in host machine or in container.

My host machine info:
#cat /etc/system-release
Red Hat Enterprise Linux Server release 7.5 (Maipo)
#docker version
Package version: docker-1.13.1-91.git07f3374.el7.centos.x86_64

Docker image I tried:
archlinux
docker run --rm -d -v /script:/script -ti --name cve-test archlinux/base
centos
docker run --rm -d -v /script:/script -ti --name cve-test centos
nginx
docker run --rm -d -v /script:/script -ti --name cve-test nginx

in host machine output:
when I use centos&nginx image, output like this:
/proc/self/exe: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory
when I use archlinux image, it's different from previous:
/proc/self/exe: error while loading shared libraries: libcrypto.so.10: cannot open shared object file: No such file or directory

And there is no /tmp/shadow folder created

[Frichetten]

Just to be sure could you do the following steps.

1. Run the command "docker run --rm -v /script:/script -it --name cve-test ubuntu"
2. Inside that container run the exploit.
3. In a different terminal window run "docker exec -it cve-test /bin/sh"

And see what that output is. Here is a gif as an example.

I haven't testing this on Red Hat so I'm curious if it is not vulnerable. Do you have SELinux enabled? That should prevent this exploit, which is why it may not be working.

[gm12367]

I tested on Ubuntu 16.04.5 LTS, still didn't work, my environment as below:

pdu@cve-test:~$ docker version
Client:
 Version:      17.03.2-ce
 API version:  1.27
 Go version:   go1.6.2
 Git commit:   f5ec1e2
 Built:        Thu Jul  5 23:07:48 2018
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.2-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.6.2
 Git commit:   f5ec1e2
 Built:        Thu Jul  5 23:07:48 2018
 OS/Arch:      linux/amd64
 Experimental: false
pdu@cve-test:~$ uname -r
4.4.0-131-generic
pdu@cve-test:~$ docker-runc --version
runc version 1.0.0-rc2
commit: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
spec: 1.0.0-rc2-dev
pdu@cve-test:~$ cat /etc/issue
Ubuntu 16.04.5 LTS \n \l

Output:

#docker exec -ti cve-test /bin/sh
/proc/self/exe: error while loading shared libraries: libapparmor.so.1: cannot open shared object file: No such file or directory

I tried to use docker file which you updated today to build a image, then I tried to use this image to trigger the exploit, still the same error output:

root@cve-test:~/cve-2019-5736-poc# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
cve                 latest              b39bab02922f        24 seconds ago      412 MB
ubuntu              18.04               47b19964fb50        12 days ago         88.1 MB
ubuntu              latest              47b19964fb50        12 days ago         88.1 MB
root@cve-test:~/cve-2019-5736-poc# docker run cve

/entrypoint: error while loading shared libraries: libapparmor.so.1: cannot open shared object file: No such file or directory

Accord to https://access.redhat.com/security/cve/cve-2019-5736, I tried to test on RHEL7.5 with docker version docker-1.13.1-88.git07f3374.el7.x86_64, because this version of docker and runc contain the vulnerability.

[root@node-10-210-139-246 ~]# docker version
Client:
 Version:         1.13.1
 API version:     1.26
 Package version: docker-1.13.1-88.git07f3374.el7.x86_64
 Go version:      go1.10.2
 Git commit:      07f3374/1.13.1
 Built:           Thu Dec  6 07:01:49 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: docker-1.13.1-88.git07f3374.el7.x86_64
 Go version:      go1.10.2
 Git commit:      07f3374/1.13.1
 Built:           Thu Dec  6 07:01:49 2018
 OS/Arch:         linux/amd64
 Experimental:    false

[root@node-10-210-139-246 ~]# /usr/libexec/docker/docker-runc-current --version
runc version spec: 1.0.0-rc2-dev

This time I got the expected result which is as the same as yours when I tried to attached container, but the exploit still not triggered. Container just stay on first stage.
host output:

#docker exec -ti cve-test /bin/sh
No help topic for '/bin/sh'

Container output:

# ./main
[+] Overwritten /bin/sh successfully

So I don't know if I get "loading shared libraries" error then it means my host contained the CVE fix, because after I update docker version, I will get this error instead of "No help topic for '/bin/sh'".
I have a look at "opencontainers/runc@0a8e411#diff-c76fda6ad413becbb91b3db6f99f0f31", it contain clone_binary verification code, but I don't know if my output is expected when I am running this exploit with CVE fix.

[Frichetten]

I tried to use docker file which you updated today to build a image, then I tried to use this image to trigger the exploit

There isn't a Dockerfile in this repository. What Dockerfile are you using? You shouldn't need one for this version of the exploit.

Just to be clear your host OS is Ubuntu? If that is the case, do not use a Dockerfile, use a regular container image with either Ubuntu or Debian (for example). Once that container is active, execute the Go binary inside of it. Then run "docker exec -it container /bin/sh".

I've tested this with a stock version of Ubuntu 18.04 running in a VM with Docker 18.03.1-ce (what is in the Gif). Could you try following the Gif step by step? You can compile main.go inside a golang container.

[gm12367]

Absolutely I followed the same steps as you, I combined your main.go named "main", please check below, if I missed anything, please tell me:

root@cve-test:/script# pwd
/script
root@cve-test:/script# ls -l
total 2048
-rwxr-xr-x 1 pdu pdu 2096403 Feb 19 02:03 main
root@cve-test:/script# cat /etc/issue
Ubuntu 16.04.5 LTS \n \l

root@cve-test:/script# docker --version
Docker version 17.03.2-ce, build f5ec1e2
root@cve-test:/script# docker run --rm -v /script:/script -it --name cve-test ubuntu
root@b18242e3a6c6:/# cd /script/
root@b18242e3a6c6:/script# ./main
[+] Overwritten /bin/sh successfully

Opened another terminal window:

root@cve-test:~# ls /tmp/shadow
ls: cannot access '/tmp/shadow': No such file or directory
root@cve-test:~# docker exec -it cve-test /bin/sh
/proc/self/exe: error while loading shared libraries: libapparmor.so.1: cannot open shared object file: No such file or directory

To be honest, I tried other code which have been written with C, I will get the same result. So I'm some mess for now.

Which I mentioned the Docker file is on the "Example of malicious Docker image" part in your Readme, url is https://github.com/q3k/cve-2019-5736-poc

[Frichetten]

That's so strange. Sorry man, I don't know what to tell you. I'd encourage you to try some of the other PoCs.

https://github.com/q3k/cve-2019-5736-poc (the coolest one in my opinion)
https://github.com/singe/container-breakouts
https://github.com/feexd/pocs
https://www.exploit-db.com/exploits/46369

[gm12367]

Dear Author
Just want to tell you my final test.I completely accord the version of Ubuntu and docker version which you mentioned about, finally I got the expected result.

root@cve-test:~/cve-test/cve-2019-5736-poc# docker run --rm -v /script:/script -it --name cve-test ubuntu
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
6cf436f81810: Pull complete
987088a85b96: Pull complete
b4624b3efe06: Pull complete
d42beb8ded59: Pull complete
Digest: sha256:7a47ccc3bbe8a451b500d2b53104868b46d60ee8f5b35a24b41a86077c650210
Status: Downloaded newer image for ubuntu:latest
root@e6e0ccc4f6f2:/# cd /script/
root@e6e0ccc4f6f2:/script# ./main
[+] Overwritten /bin/sh successfully
[+] Found the PID: 18
[+] Successfully got the file handle
[+] Successfully got write handle &{0xc0000f4600}

root@cve-test:~# docker exec -it cve-test /bin/sh
No help topic for '/bin/sh'
root@cve-test:~# ls /tmp
config-err-CeJXfg
shadow
ssh-XjTYfZHI2YNH
systemd-private-62de4765225a4c2bb3103de39fd08093-bolt.service-1LY3tg
systemd-private-62de4765225a4c2bb3103de39fd08093-colord.service-wszEPe
systemd-private-62de4765225a4c2bb3103de39fd08093-fwupd.service-xJkpbz
systemd-private-62de4765225a4c2bb3103de39fd08093-rtkit-daemon.service-VEsmgm
systemd-private-62de4765225a4c2bb3103de39fd08093-systemd-resolved.service-zUwKab
systemd-private-62de4765225a4c2bb3103de39fd08093-systemd-timesyncd.service-Z1AVOI
Temp-6d205512-2f94-42a2-9cba-dad8c1e39340
Temp-d4bb7285-c842-4390-9e51-5b8ac10bb1cd
tmp9tadi7fk
tmpaddon
tmpnehtbxup

At last, I tested with docker of version 18.09.2(it contained the CVE fix), exploit didn't trigger, and /tmp/shadow not created as well, but there is not anymore with library error output,I think it's expected.

root@bec3990567e1:/# /script/main
[+] Overwritten /bin/sh successfully
[+] Found the PID: 18
[+] Successfully got the file handle

So maybe this exploit just work on some fixed docker version?

[Frichetten]

@mikaelkall, thanks for the heads up! When I get some free time I will look into modifications to get it working in 16.04.

@gm12367, glad that worked for you!

[Frichetten]

This issue identified some gaps in which Host OS's are vulnerable (not to the vulnerability, but to this exploit). I have updated the README to reflect this and when I get the free time I will explore what can be done to exploit those OS's as well. I will close this issue.

For those interested the original exploit code can be found here: https://www.openwall.com/lists/oss-security/2019/02/13/3

For some reason that link seems to go down frequently, however I was able to grab the exploit code from it.