A fix for CVE-2016-9962 was released in Docker upstream 1.12.6 a couple of days ago.
Docker: insecure opening of file-descriptor allows privilege escalation
11–20 of 23 posts
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#12Oh good, yet another vulnerability from the model of retroactively changing the execution environment of a process after it's been created. We had a thread about setuid binaries a week ago, which is the most common case of this design: https://news.ycombinator.com/item?id=13312722 We would all be better off if we designed systems such that some helper process, already running with the right environment / config / pri…
I think that is closer to how you do things in Windows, first set up the process environment and finally call CreateProcess or something like that. Maybe someone who knows Win32/NT internals better could comment?
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#13For those that won't open the link :) Update by Trevor Jay: "This is an extremely difficult to exploit flaw on standard RHEL and Fedora systems. I checked the 1.10.3 and 1.12.5 builds on Brew. Both drop the `CAP_SYS_PTRACE` capability by default. 1.10.3 blacklists `ptrace` calls under the default seccomp profile. Thus, this flaw only comes into play for containers that already have elevated privileges. Even if `ptrac…
Gotta love modern computing and defense in depth. Sometimes it actually really helps despite feeling like a hassle at times.
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#14For those that won't open the link :) Update by Trevor Jay: "This is an extremely difficult to exploit flaw on standard RHEL and Fedora systems. I checked the 1.10.3 and 1.12.5 builds on Brew. Both drop the `CAP_SYS_PTRACE` capability by default. 1.10.3 blacklists `ptrace` calls under the default seccomp profile. Thus, this flaw only comes into play for containers that already have elevated privileges. Even if `ptrac…
Gotta love modern computing and defense in depth. Sometimes it actually really helps despite feeling like a hassle at times.
Every once in a while I'll say something along the lines of "Wouldn't it be nice if there was " or "wouldn't it be nice if you could " etc. and get enthusiastic nods, disbelief or "if only" and have to break it to someone that they don't know what the hell they're doing and they simply overlooked a huge feature of their production platform.
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#15I discovered the vulnerability, and I'm not entirely sure that Trevor Jay fully understands the issue (though to be fair, the easiest way of exploiting it is using ptrace(2) which is blocked by most default security policies). You don't need to use ptrace(2) or CAP_SYS_PTRACE to exploit the vulnerability.
You just need to have proc_fd_access_allowed(). I've not checked if ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS) calls into SELinux hooks (it probably does, and if it doesn't then resolving further files probably does too) but neither seccomp profiles (unless you're blocking open(2)) nor blocking CAP_SYS_PTRACE can help you here.
Now, the LXC exploit used ptrace in order to stop the process from closing its file descriptors. I'm not sure how you would reliably hit the race in this issue (something with SIGSTOP presumably?).
In any case, SUSE's update has additional fixes which also fix the issue even when you give a container CAP_SYS_PTRACE (the released patch does _not_ protect containers that have CAP_SYS_PTRACE enabled). The patches will be merged upstream ASAP, but Docker didn't want them in the patchset sent to its customers (preferring instead to update their vendored runC once they are merged upstream).
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#16CoreOS engineers started deploying patches across all channels for this CVE minutes after it was made public. More info here: https://coreos.com/blog/cve-2016-9962.html
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#17is there a poc? would love to see a walkthrough
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#18I discovered the vulnerability, and I'm not entirely sure that Trevor Jay fully understands the issue (though to be fair, the easiest way of exploiting it is using ptrace(2) which is blocked by most default security policies). You don't need to use ptrace(2) or CAP_SYS_PTRACE to exploit the vulnerability. You just need to have proc_fd_access_allowed(). I've not checked if ptrace_may_access(task, PTRACE_MODE_READ_FSCR…
Sorry for not seeing your comment until now. Amazingly great vuln BTW. It's early in 2017, but this is probably going to be one of this year's best.
It's very important for everyone to understand my advice is RHEL/Fedora specific, which is---I think---the source of the misunderstanding here.
Putting aside `ptrace` being the best way to guarantee a race win, the reason for my focus on `CAP_SYS_PTRACE` is that with SELinux enabled there is no other way to exploit having access to the file descriptors. Even if you explicitly try to pass a containerized process an external file descriptor "legitimately" (e.g. with `sendmsg`) SELinux will still ultimately block the access due to the type restrictions. This means that with `setenforce 1` you need to use something like code injection to get the external process to access the file descriptors on your behalf.
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#19Oh good, yet another vulnerability from the model of retroactively changing the execution environment of a process after it's been created. We had a thread about setuid binaries a week ago, which is the most common case of this design: https://news.ycombinator.com/item?id=13312722 We would all be better off if we designed systems such that some helper process, already running with the right environment / config / pri…
I've often wondered what it would take to have a linux environment with setuid completely turned off, and this is actually a really interesting thought on how to achieve part of that. Nice. :)
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#20I discovered the vulnerability, and I'm not entirely sure that Trevor Jay fully understands the issue (though to be fair, the easiest way of exploiting it is using ptrace(2) which is blocked by most default security policies). You don't need to use ptrace(2) or CAP_SYS_PTRACE to exploit the vulnerability. You just need to have proc_fd_access_allowed(). I've not checked if ptrace_may_access(task, PTRACE_MODE_READ_FSCR…
Sorry for not seeing your comment until now. Amazingly great vuln BTW. It's early in 2017, but this is probably going to be one of this year's best. It's very important for everyone to understand my advice is RHEL/Fedora specific, which is---I think---the source of the misunderstanding here. Putting aside `ptrace` being the best way to guarantee a race win, the reason for my focus on `CAP_SYS_PTRACE` is that with SEL…
> Sorry for not seeing your comment until now. Amazingly great vuln BTW. It's early in 2017, but this is probably going to be one of this year's best.
Thanks. :D
> Putting aside `ptrace` being the best way to guarantee a race win, the reason for my focus on `CAP_SYS_PTRACE` is that with SELinux enabled there is no other way to exploit having access to the file descriptors. Even if you explicitly try to pass a containerized process an external file descriptor "legitimately" (e.g. with `sendmsg`) SELinux will still ultimately block the access due to the type restrictions. This means that with `setenforce 1` you need to use something like code injection to get the external process to access the file descriptors on your behalf.
Ah okay, yeah I suspected that's what you meant (on _RHEL_ xyz is the case). Thanks for clarifying.