lkml.org 
[lkml]   [2021]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v10 3/3] mm: add anonymous vma name refcounting
    On Fri, Oct 15, 2021 at 09:30:09AM -0700, Suren Baghdasaryan wrote:
    > On Fri, Oct 15, 2021 at 1:04 AM David Hildenbrand <david@redhat.com> wrote:
    > >
    > > On 14.10.21 22:16, Suren Baghdasaryan wrote:
    > > > [...]
    > > > 3. Leaves an fd exposed, even briefly, which may lead to unexpected
    > > > flaws (e.g. anything using mmap MAP_SHARED could allow exposures or
    > > > overwrites). Even MAP_PRIVATE, if an attacker writes into the file
    > > > after ftruncate() and before mmap(), can cause private memory to be
    > > > initialized with unexpected data.
    > >
    > > I don't quite follow. Can you elaborate what exactly the issue here is?
    > > We use a temporary fd, yes, but how is that a problem?
    > >
    > > Any attacker can just write any random memory memory in the address
    > > space, so I don't see the issue.
    >
    > It feels to me that introducing another handle to the memory region is
    > a potential attack vector but I'm not a security expert. Maybe Kees
    > can assess this better?

    This case is kind of just an extension of "we don't need an fd, we need
    a name". There is a lot of resulting baggage suddenly added to using
    anonymous VMA (fork overhead to deal with the fds, etc), but for me, this
    particular situation above is what really demonstrates the "unexpected
    side-effects" of trying to swap an anonymous mmap for a memfd: there is
    now an _external handle_ attached to memory that doesn't pass through
    any of the existing security boundaries normally associated with process
    memory (i.e. ptrace). Here's the example race:

    victim process attacker process (same uid)
    memfd_create(name, flags);
    -> /proc/$pid/fd/3
    ftruncate(3, size);
    open("/proc/$victim/fd/3", O_RDWR)
    -> 3
    mmap(NULL, size,
    PROT_READ | PROT_WRITE | PROT_EXEC,
    MAP_SHARED, 3, 0);
    -> addr
    memset(addr, 0xFF, size);

    mmap(NULL, size, prot,
    MAP_PRIVATE, 3, 0);
    -> addr
    close(3);

    surprise, addr[0] != 0x00

    And again, yes, we could program defensively, but it's a surprising
    situation with new corner cases that haven't been present for years of
    Just Using Anon VMAs. :) I would be worried about other vectors we
    haven't imagined yet.

    So, I think between both the overhead of files and the expanded attack
    surface make memfd unsuited for this use-case.

    -Kees

    --
    Kees Cook

    \
     
     \ /
      Last update: 2021-10-15 19:46    [W:4.225 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site