[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALCETrW=hBTZM0=6PB1ALe8EUZiBEM26JjCTbMFvVfGsVPZGyA@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
