3 ms·

I 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 us

by cyphar 10y ago

I 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).

gtjay 10y ago
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.
- cyphar 10y ago
  > 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.
  - gtjay 10y ago
    > [...] 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.

by cyphar 10y ago

gtjay 10y ago

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.

cyphar 10y ago
> 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.
- gtjay 10y ago
  > [...] 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.