Docker: insecure opening of file-descriptor allows privilege escalation • Hacker News Board

Re: Docker: insecure opening of file-descriptor allows privilege escalation

#21

Post by gtjay » Fri, Jan 13, 2017, 4:19 AM UTC

cyphar wrote: post #20

gtjay wrote: post #18

Earlier quoted context omitted.

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 contain…

> [...] you meant (on _RHEL_ xyz is the case) [...] >

Totally on me. We fight against it, but it's hard not to have the implicit context of RHEL/Fed be omnipresent on the Red Hat bugzilla. In fact, when I wrote the comment in question I had just finished lighting my incense to the sīla of `systemd`... :)

Did not realize you were in Sydney. AU truly has the best hackers.

Re: Docker: insecure opening of file-descriptor allows privilege escalation

#22

Post by aaronmdjones » Fri, Jan 13, 2017, 2:50 PM UTC

mnarayan01 wrote: post #7

geofft wrote: post #2

Oh 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.

Along with the aforementioned IPPROTO_ICMP; you can still use file capabilities(7) instead (or as well, in the case of older kernels):

# chmod 0711 /bin/ping # setcap CAP_NET_RAW=eip /bin/ping

Re: Docker: insecure opening of file-descriptor allows privilege escalation

#23

Post by geofft » Fri, Jan 13, 2017, 3:40 PM UTC

aaronmdjones wrote: post #22

mnarayan01 wrote: post #7

Earlier quoted context omitted.

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.

Along with the aforementioned IPPROTO_ICMP; you can still use file capabilities(7) instead (or as well, in the case of older kernels): # chmod 0711 /bin/ping # setcap CAP_NET_RAW=eip /bin/ping

File capabilities are certainly better than setuid, but they still have the same problem of elevating privileges in a potentially-attacker-controlled environment. If setuid ping has a vulnerability that lets you get root, CAP_NET_RAW ping would also have a vulnerability that lets you read all traffic into the machine and spoof packets from privileged ports or existing connections. That's an uncomfortably large amount of access, even if it isn't quite root.