Date: Wed, 13 Aug 2014 09:47:25 -0700 From: Andy Lutomirski <luto@...capital.net> To: oss-security@...ts.openwall.com Subject: Re: CVE Request: ro bind mount bypass using user namespaces [sorry for awkward threading] On Tue, Aug 12, 2014 at 4:54 PM, Andy Lutomirski <luto@...capital.net> wrote: > On 08/12/2014 02:48 PM, Kenton Varda wrote: >> Due to a bug in the Linux kernel's implementation of remount, on systems >> with unprivileged user namespaces enabled, it is possible for an >> unprivileged user to gain write access to any visible read-only bind mount. >> It is also possible to bypass flags like nodev, nosuid, and noexec. >> >> This problem affects sandboxing / containerization systems that do not >> expose the regular filesystem to the sandboxed process, but do expose a >> bind-mounted view of that filesystem using these flags to enforce security. >> This bug may enable a sandbox break-out. Sandboxes which have used >> seccomp-bpf to disable the "mount" system call or to disable user >> namespaces are likely safe. > > nosuid/nodev failures are probably exploitable for full root in many > common configurations. These vulnerabilities only exist if you can unshare your user namespace, which, as a practical matter, requires a 3.12-ish or newer kernel. (I think the option was available earlier, but I don't think any distros enabled it.) You need CONFIG_USER_NS=y and, if you have some patch that lets you turn off user namespaces (is that what kernel.unpriv_user_ns or whatever is? it's not there on my system), then you *may* be safe. Note that, even if only root can unshare user namespaces, it's still plausible that code in a userns sandbox could use these bugs to root the host. I've attached a test case for CVE-2014-5207. This test demonstrates the problem, but it shouldn't be able to harm the system it runs on. You can run it as root or as an unprivileged user. Note that, if you're using whatever patch adds that sysfs entry, it's probably worth running the test case as root, but it may still fail. If it doesn't explicitly report that you're safe, then you shouldn't take its output to mean that you're safe; the hardening patch may interfere with this particular test, even if it wouldn't prevent an exploit. Kenton, want to post your test for the -5206 issue? --Andy View attachment "check_CVE-2014-5207.c" of type "text/x-csrc" (2508 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ