Re: Denial of service attack via libpager

[Brent W. Baccala]

On Sun, Aug 28, 2016 at 12:49 PM, Richard Braun <rbraun@sceen.net> wrote:

I'm really not seeing the relation between "multiple clients" and
"multiple threads". Libpager must be able to handle multiple clients
with a single thread, otherwise we don't control scalability and we're
back to where we were before Justus' rework...

Are you referring to the work about two years ago to use a fixed number of threads?

libpager handles multiple clients with a single thread, but I don't think it can handle multiple clients for a single file.

In ext2fs/ext2fs.h, we find:

/* ext2fs specific per-file data.  */
struct disknode
{
  ...
  /* This file's pager.  */
  struct pager *pager;
  ...
};

which suggests a single struct pager for each file, right?  And in libpager/priv.h, we find:

struct pager
{
  ...
  /* Interface ports */
  memory_object_control_t memobjcntl;
  memory_object_name_t memobjname;
  ...
};

which suggests only a single client, with a single pair of control/name ports, for each struct pager.

I'm saying that the struct pager needs to have a list of multiple clients, with multiple control/name port pairs.

 

And again, I think it's much easier and much more helpful to change
exec and others to _avoid_ mmap, and copy the data in instead,
possibly (and in this case probably) with zero-copy.

I should elaborate on what I found with exec.  After I fixed the problem with the exec server mmap'ing the library's ELF headers, it just got on a little bit further in the process, and then croaked when it tried to mmap the program binary itself.

Assume two hosts, Alice and Bob.  Alice has mounted a remote file system from Bob and now tries to execute a file residing on Bob.  So we have the new task and the shared libraries, both on Alice, and the exec server and the program binary, both on Bob.  Bob's exec server will try to mmap the shared library headers into its own address space to examine them, which is a problem.  Once we get past that point, the exec server tries to mmap the program binary (on Bob) into the new task (on Alice).  Bob's ext2fs translator now has a new memory object client - Alice's kernel.

So we still have to mmap across the network.  We certainly don't want to avoid mmap's entirely for program text and (especially) for shared libraries.  Although I admit that it would be best to detect when the mmap fails and fall back on ordinary reads.

 

Finally, I fail to see how making libpager handle multiple clients
will solve that issue. The only client should be the local kernel,
right ?

The obvious additional client would be a remote kernel, but as the exploit program that I posted shows, it could just as easily be an unprivileged process.  You don't need much permission to get a memory object, just read access on the file.

    agape

    brent