Docker: insecure opening of file-descriptor allows privilege escalation
bugzilla.redhat.com
Docker: insecure opening of file-descriptor allows privilege escalation
1–10 of 23 posts
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#2Oh 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 / privileges, spawns the process for you and proxies input/output to your terminal.
And (as I mentioned in the other thread) this helper process could be literally sshd. Instead of having sudo, ssh root@localhost. No weird process trees with confusing things like effective UIDs. Instead of having runc exec, ssh root@container. No file descriptors get passed that aren't explicitly forwarded over the SSH connection.
Patching sshd to run over UNIX sockets without encryption and to use getpeername() for authentication is left as an exercise to the reader.
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#3Oh 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…
No patches nessecary :) I use this quite successfully in my ~/.ssh/config currently. With some options baked on, You probably could disable encryption too:
Host web
LogLevel QUIET
ForwardAgent yes
ProxyCommand setsid lxc-attach -q -n web01 --clear-env -- /usr/sbin/sshd -iRe: Docker: insecure opening of file-descriptor allows privilege escalation
#4Oh 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…
No patches nessecary :) I use this quite successfully in my ~/.ssh/config currently. With some options baked on, You probably could disable encryption too: Host web LogLevel QUIET ForwardAgent yes ProxyCommand setsid lxc-attach -q -n web01 --clear-env -- /usr/sbin/sshd -i
Hah, that is so close to the design I'm advocating, except that lxc-attach is yet another command in the mold of runc exec or sudo :-)
That design certainly lets lxc-attach permit only running sshd, though, which is a benefit. (And I forgot about sshd -i, which you could presumably point at a UNIX socket using socat or something.)
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#5Oh 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…
The Go ssh library works fine over unix sockets, and you can easily customise auth, so it is pretty easy to make quick custom clients and servers with it.
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#6For 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 `ptrace` is available. The proposed exploit scenario of quickly attaching to a process joining the container space and using its file descriptors is not possible under the default SELinux configuration. The containerized PID 1 will have a type of `container_t` or similar SELinux type and thus will be blocked by standard type enforcement from accessing accessing any resources that haven't already been made available to containerized processes."
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#7Oh 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…
How would you implement e.g. ping? I mean obviously you could have e.g. user accounts which were "sufficiently" locked down, but that seems like an even more likely source of problems.
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#8Oh 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…
How would you implement e.g. ping? I mean obviously you could have e.g. user accounts which were "sufficiently" locked down, but that seems like an even more likely source of problems.
Linux supports non privileged ping. socket(PF_INET, SOCK_DGRAM IPPROTO_ICMP); (it needs a sysctl config to enable it, annoyingly)
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#9Oh 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…
How would you implement e.g. ping? I mean obviously you could have e.g. user accounts which were "sufficiently" locked down, but that seems like an even more likely source of problems.
Three options:
1. ping hasn't needed to be setuid since Linux 3.0 (and isn't on most distros), the kernel lets you call socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) without privileges, which lets you send ping packets and nothing else. Looks like Mac OS X and FreeBSD, at least, also support the same interface. This approach has successfully been used to eliminate other setuid binaries like pt_chown, which fixes ownership of a tty (the kernel now just sets the ownership correctly when you call open).
2. Use something like ForceCommand to allow "ssh root@localhost /sbin/ping", and make /bin/ping a shell script that does that. This carries strictly less complexity than making a setuid binary; any attack that applies to it also applies to setuid binaries, but the execution environment for setuid binaries is more open to the attacker's control.
3. Make a little ping server that you can request to conduct pings for you. For ping in particular this is probably silly, but for things like updating utmp (traditionally you make every program setgid utmp, or you use a helper setgid binary called utempter), there's probably some existing daemon like logind that can grow some small APIs.
Re: Docker: insecure opening of file-descriptor allows privilege escalation
#10For 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…
For anyone who is annoyed by SElinux enough to drop it, which is most people, and anyone who would ever like to ptrace a process, which is most people, or anyone who doesn't use distros like these with these default protections for container processes, it's still viable.