This POC won't work for me
gm12367 opened this issue · 12 comments
Dear author:
I tried your POC file, but it didn't work, because there is a existed pid named runc in /proc//cmdline
I tried with this bash script:
while true; do
for pid in $(ps -ef | awk '{print $2}'); do
cmdline=$(cat /proc/${pid}/cmdline)
if [[ ${cmdline} == *runc* ]]; then
echo !!!!!!!!!!!!!!!!!!!!!!!!!runc was found!!!!!!!!!!!!!!!!!!!!!!!
echo pid:${pid}
fi
done
done
and the output like this:
cat: /proc/876/cmdline: No such file or directory
cat: /proc/877/cmdline: No such file or directory
cat: /proc/878/cmdline: No such file or directory
cat: /proc/PID/cmdline: No such file or directory
！！！！！！！！runc was found ！！！！！！！！！！！！！
pid:25
So this exploit will not work for me
And when I execute the go binary file, second time when I want execute docker exec command, an error will occurred to prevent this POC
docker exec -ti runc-test /bin/sh
/proc/self/exe: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory
Appreciated
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?
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
Just to be sure could you do the following steps.
- Run the command "docker run --rm -v /script:/script -it --name cve-test ubuntu"
- Inside that container run the exploit.
- 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.
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.
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.
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.
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
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
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
endDear 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?
@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!
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.