内核驱动mmap Handler利用技术（一）

2018-01-16 玉涵看雪学院

1. 内核驱动简介

在实现Linux内核驱动中，开发者可以注册一个设备驱动文件，该文件常常在/dev/目录下完成注册。该文件可以支持所有的常规文件方法，比如opening, reading, writing, mmaping, closing等等。设备驱动文件支持的操作由包含了一组函数指针的结构体file_operations描述，每个指针描述一个操作。在4.9版本内核中可以找到如下的定义。

struct file_operations {
  struct module *owner;
  loff_t(*llseek) (struct file *, loff_t, int);
  ssize_t(*read) (struct file *, char __user *, size_t, loff_t *);
  ssize_t(*write) (struct file *, const char __user *, size_t,     loff_t *);
  ssize_t(*read_iter) (struct kiocb *, struct iov_iter *);
  ssize_t(*write_iter) (struct kiocb *, struct iov_iter *);
  int(*iterate) (struct file *, struct dir_context *);
  int(*iterate_shared) (struct file *, struct dir_context *);
  unsigned int(*poll) (struct file *, struct poll_table_struct *);
  long(*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
  long(*compat_ioctl) (struct file *, unsigned int, unsigned long);
  int(*mmap) (struct file *, struct vm_area_struct *);
  int(*open) (struct inode *, struct file *);
  int(*flush) (struct file *, fl_owner_t id);
  int(*release) (struct inode *, struct file *);
  int(*fsync) (struct file *, loff_t, loff_t, int datasync);
  int(*fasync) (int, struct file *, int);
  int(*lock) (struct file *, int, struct file_lock *);
  ssize_t(*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
  unsigned long(*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
  int(*check_flags)(int); int(*flock) (struct file *, int, struct file_lock *);
  ssize_t(*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
  ssize_t(*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
  int(*setlease)(struct file *, long, struct file_lock **, void **);
  long(*fallocate)(struct file *file, int mode, loff_t offset,loff_t len);
  void(*show_fdinfo)(struct seq_file *m, struct file *f);
#ifndef CONFIG_MMU
  unsigned(*mmap_capabilities)(struct file *);
#endif
  ssize_t(*copy_file_range)(struct file *, loff_t, struct file *, loff_t, size_t, unsigned int);
  int(*clone_file_range)(struct file *, loff_t, struct file *, loff_t,u64);
  ssize_t(*dedupe_file_range)(struct file *, u64, u64, struct file *, u64);
};

如同上面展示，可以实现非常多的文件操作，本文的主角是mmap handler的实现。

file_operations结构体的安装示例以及相关联的函数可以在下面看到

（'/fs/proc/softirqs.c'）:

static int show_softirqs(struct seq_file *p, void *v)
{
  int i, j;

  seq_puts(p, " ");
  for_each_possible_cpu(i)
    seq_printf(p, "CPU%-8d", i);
  seq_putc(p, '\n');

  for (i = 0; i < NR_SOFTIRQS; i++)
  {
    seq_printf(p, "%12s:", softirq_to_name[i]);
    for_each_possible_cpu(j)
      seq_printf(p, " %10u", kstat_softirqs_cpu(i, j));
    seq_putc(p, '\n');
  }
  return 0;
}

static int softirqs_open(struct inode *inode, struct file *file)
{
  return single_open(file, show_softirqs, NULL);
}

static const struct file_operations proc_softirqs_operations = {
  .open = softirqs_open,
  .read = seq_read,
  .llseek = seq_lseek,
  .release = single_release,
};

static int __init proc_softirqs_init(void)
{
  proc_create("softirqs", 0, NULL, &proc_softirqs_operations);
  return 0;
}

上述代码可以在'proc_softirqs_operations'结构体中看到，它允许调用open, read, llseek和close函数。当一个应用程序试图去打开一个'softirqs'文件时就会调用'open'系统调用，进而会调用到指向的'softirqs_open'函数。

2. 内核mmap Handler

2.1 简单的mmap Handler

如上文提及，内核驱动可以实现自己的mmap handler。主要目的在于mmap handler可以加速用户空间进程和内核空间的数据交换。内核可以共享一块内核buffer或者直接共享某些物理内存地址范围给用户空间。用户空间进程可以直接修改这块内存而无需调用额外的系统调用。

一个简单（并且不安全）的mmap handler实现例子如下：

static struct file_operations fops =
{
  .open = dev_open,
  .mmap = simple_mmap,
  .release = dev_release,
};

int size = 0x10000;

static int dev_open(struct inode *inodep, struct file *filep)
{
  printk(KERN_INFO "MWR: Device has been opened\n");
&nbsp 41 36499 41 15233 0 0 4400 0 0:00:08 0:00:03 0:00:05 4400;filep->private_data = kzalloc(size, GFP_KERNEL);
  if (filep->private_data == NULL)
    return -1;
  return 0;
}

static int simple_mmap(struct file *filp, struct vm_area_struct *vma)
{
  printk(KERN_INFO "MWR: Device mmap\n");
  if ( remap_pfn_range( vma, vma->vm_start, virt_to_pfn(filp->private_data), vma->vm_end - vma->vm_start, vma->vm_page_prot ) )
  {
    printk(KERN_INFO "MWR: Device mmap failed\n");
    return -EAGAIN;
  }
  printk(KERN_INFO "MWR: Device mmap OK\n");
  return 0;
}

当打开上面的驱动时，dev_open会被调用，它简单的分配0x10000字节的buffer并且将其保存在private_data指针域。此后如果进程在对该文件描述符调用mmap时，就会调用到simple_mmap。

该函数简单的调用 remap_pfn_range 函数来创建一个进程地址空间的新映射，将private_data指向的buffer和vma->vm_start开始的尺寸为vma->vm_end-vma->vm_start 大小的地址空间关联起来。

一个请求对应文件mmap的用户空间程序样例：

int main(int argc, char * const * argv)
{
  int fd = open("/dev/MWR_DEVICE", O_RDWR);
  if (fd < 0)
  {
    printf("[-] Open failed!\n");
    return -1;
  }

  unsigned long * addr = (unsigned long *)mmap((void*)0x42424000, 0x1000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x1000);
  if (addr == MAP_FAILED)
  {
    perror("Failed to mmap: ");
    close(fd);
    return -1;
  }
  printf("mmap OK addr: %lx\n", addr);
  close(fd);
  return 0;
}

上面的代码对/dev/MWR_DEVICE驱动文件调用了mmap，大小为0x1000，文件偏移设置为0x1000，目标地址设置为0x42424000。可以看到一个成功的映射结果：

# cat /proc/23058/maps
42424000-42425000 rw-s 00001000 00:06 68639 /dev/MWR_DEVICE

2.2 空的mmap Handler

到目前为止，我们已经见过了最简单的mmap操作的实现体，但是如果mmap handler是个空函数的话，会发生什么？

让我们考虑这个实现：

static struct file_operations fops =
{
  .open = dev_open,
  .mmap = empty_mmap,
  .release = dev_release,
};

static int empty_mmap(struct file *filp, struct vm_area_struct *vma)
{
  printk(KERN_INFO "MWR: empty_mmap\n");
  return 0;
}

如我们所见，函数中只有log信息，这是为了让我们观察到函数被调用了。

当empty_mmap被调用时，我们毫不夸张的可以猜测到什么都不会发生，mmap会引发失败，毕竟此时并没有remap_pfn_range或其他类似的函数。

然而，事实并非如此。让我们运行一下用户空间代码，看看究竟会发生什么：

int fd = open("/dev/MWR_DEVICE", O_RDWR);
unsigned long size = 0x1000;
unsigned long *addr = (unsigned long *)mmap((void*)0x42424000, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x1000);

在dmesg log中我们可以看到空的handler被成功调用：

[ 1119.393560] MWR: Device has been opened 1 time(s)
[ 1119.393574] MWR: empty_mmap

看看内存映射，有没有什么异常：

# cat /proc/2386/maps
42424000-42426000 rw-s 00001000 00:06 22305

我们并没有调用remap_pfn_range函数，然而映射却如同此前情景那样被创建了。唯一的不同在于映射是无效的，因为我们实际上并没有映射任何的物理内存给这块虚拟地址。这样的一个mmap实现中，一旦访问了映射的地址空间，要么引起进程崩溃，要么引起整个内核的崩溃，这取决于具体使用的内核。

让我们试试访问这块内存：

int fd = open("/dev/MWR_DEVICE", O_RDWR);
unsigned long size = 0x1000;
unsigned long * addr = (unsigned long *)mmap((void*)0x42424000, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x1000); printf("addr[0]: %x\n", addr[0]);

如我们所愿，进程崩溃了：

./mwr_client
Bus error

然而在某些3.10 arm/arm64 Android内核中，类似的代码会引起kernel panic。

所以说，作为一个开发者，你不应该假定一个空的handler可以按预期表现，在内核中始终使用一个可用的返回码来控制给定的情形。

一个带有vm_operations_struct的mmap Handler

在mmap操作中，有办法在已分配内存区间上使用vm_operations_struct结构体来指派多种其他操作的handler（例如控制unmapped memory, page permission changes等）。

vm_operations_struct在kernel 4.9中的定义如下：

struct vm_operations_struct {
  void(*open)(struct vm_area_struct * area);
  void(*close)(struct vm_area_struct * area);
  int(*mremap)(struct vm_area_struct * area);
  int(*fault)(struct vm_area_struct *vma, struct vm_fault *vmf);
  int(*pmd_fault)(struct vm_area_struct *, unsigned long address, pmd_t *, unsigned int flags);
  void(*map_pages)(struct fault_env *fe, pgoff_t start_pgoff, pgoff_t end_pgoff);
  int(*page_mkwrite)(struct vm_area_struct *vma, struct vm_fault *vmf);
  int(*pfn_mkwrite)(struct vm_area_struct *vma, struct vm_fault *vmf);
  int(*access)(struct vm_area_struct *vma, unsigned long addr, void *buf, int len, int write);
  const char *(*name)(struct vm_area_struct *vma);
#ifdef CONFIG_NUMA
  int(*set_policy)(struct vm_area_struct *vma, struct mempolicy *new);
  struct mempolicy *(*get_policy)(struct vm_area_struct *vma, unsigned long addr);
#endif
  struct page *(*find_special_page)(struct vm_area_struct *vma, unsigned long addr);
};

如上文描述，这些函数指针可以用于实现特定的handler。关于此的详细描述在《Linux Device Drivers（Linux设备驱动）》一书中可以找到。

在实现内存分配器时，一个通俗可见的主流的行为是开发者实现了一个'fault' handler。例如，看看这一段：

static struct file_operations fops = {
  .open = dev_open,
  .mmap = simple_vma_ops_mmap,
  .release = dev_release,
};

static struct vm_operations_struct simple_remap_vm_ops = {
  .open = simple_vma_open,
  .close = simple_vma_close,
  .fault = simple_vma_fault,
};

static int simple_vma_ops_mmap(struct file *filp, struct vm_area_struct *vma)
{
  printk(KERN_INFO "MWR: Device simple_vma_ops_mmap\n");
  vma->vm_private_data = filp->private_data;
  vma->vm_ops = &simple_remap_vm_ops;
  simple_vma_open(vma);
  printk(KERN_INFO "MWR: Device mmap OK\n");
  return 0;
}

void simple_vma_open(struct vm_area_struct *vma)
{
  printk(KERN_NOTICE "MWR: Simple VMA open, virt %lx, phys %lx\n", vma->vm_start, vma->vm_pgoff << PAGE_SHIFT);
}

void simple_vma_close(struct vm_area_struct *vma)
{
  printk(KERN_NOTICE "MWR: Simple VMA close.\n");
}

int simple_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
  struct page *page = NULL;
  unsigned long offset;
  printk(KERN_NOTICE "MWR: simple_vma_fault\n");
  offset = (((unsigned long)vmf->virtual_address - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT));
  if (offset > PAGE_SIZE << 4)
    goto nopage_out;
  page = virt_to_page(vma->vm_private_data + offset);
  vmf->page = page;
  get_page(page);
nopage_out:
  return 0;
}

上述代码中我们可以看到simple_vma_ops_mmap函数用于控制mmap调用。它什么都没做，除了指派了simple_remap_vm_ops结构体作为虚拟内存操作的handler。

让我们看看下列代码在该driver上运行的效果：

int fd = open("/dev/MWR_DEVICE", O_RDWR);
unsigned long size = 0x1000;
unsigned long * addr = (unsigned long *)mmap((void*)0x42424000, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x1000);

dmesg的结果：

[268819.067085] MWR: Device has been opened 2 time(s)
[268819.067121] MWR: Device simple_vma_ops_mmap
[268819.067123] MWR: Simple VMA open, virt 42424000, phys 1000
[268819.067125] MWR: Device mmap OK

进程地址空间的映射：

42424000-42425000 rw-s 00001000 00:06 140215 /dev/MWR_DEVICE

如我们所见，simple_vma_ops_mmap函数被调用了，内存映射也创建了。例子中simple_vma_fault函数没有被调用。

问题在于，我们有了个地址范围为0x42424000-0x42425000的地址空间却不清楚它指向何处。我们没有为它关联物理内存，因此当进程试图访问这段地址的任一部分时，simple_vma_fault都会执行。

所以让我们看看这段用户空间代码：

int fd = open("/dev/MWR_DEVICE", O_RDWR);
unsigned long size = 0x2000;
unsigned long * addr = (unsigned long *)mmap((void*)0x42424000, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x1000);
printf("addr[0]: %x\n", addr[0]);

代码唯一的改变在于使用了printf函数来访问映射内存。因为内存区域无效所以我们的simple_vma_fault例程被调用了。dmesg的输出可以看到：

[285305.468520] MWR: Device has been opened 3 time(s)
[285305.468537] MWR: Device simple_vma_ops_mmap
[285305.468538] MWR: Simple VMA open, virt 42424000, phys 1000
[285305.468539] MWR: Device mmap OK
[285305.468546] MWR: simple_vma_fault

在simple_vma_fault函数中，我们可以观察到offset变量使用了指向一个没有被映射的地址的vmf->virtual_address进行了计算。我们这里就是addr[0]的地址。

下一个page结构体由virt_to_page宏得到，该宏将新获取的page赋值给vmf->page变量。

这一赋值意味着当fault handler返回时，addr[0]会指向由simple_vma_fault计算出来的某个物理地址。该内存可以被用户进程所访问而无需其他任何代码。

如果程序试图访问addr[513]（假定sizeof(unsigned long)为8），fault handler会被再次调用，这是由于addr[0]和addr[513]在两个不同的内存页上，而此前仅有一个内存页被映射过。

这就是源码：

int fd = open("/dev/MWR_DEVICE", O_RDWR);
unsigned long size = 0x2000;
unsigned long * addr = (unsigned long *)mmap((void*)0x42424000, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x1000);
printf("addr[0]: %x\n", addr[0]);
printf("addr[513]: %x\n", addr[513]);

生成内核log：

[286873.855849] MWR: Device has been opened 4 time(s)
[286873.855976] MWR: Device simple_vma_ops_mmap
[286873.855979] MWR: Simple VMA open, virt 42424000, phys 1000
[286873.855980] MWR: Device mmap OK
[286873.856046] MWR: simple_vma_fault
[286873.856110] MWR: simple_vma_fault

3. 经典mmap Handler议题

3.1 用户输入有效性的不足

让我们看看前面的mmap handler例子：

static int simple_mmap(struct file *filp, struct vm_area_struct *vma)
{
  printk(KERN_INFO "MWR: Device mmap\n");
  if ( remap_pfn_range( vma, vma->vm_start, virt_to_pfn(filp->private_data), vma->vm_end - vma->vm_start, vma->vm_page_prot ) )
  {
    printk(KERN_INFO "MWR: Device mmap failed\n");
    return -EAGAIN;
  }
  printk(KERN_INFO "MWR: Device mmap OK\n");
  return 0;
}

前面展示的代码展示了一个通用的实现mmap handler的途径，相似的代码可以在《Linux设备驱动》一书中找到。示例代码主要的议论点在于vma->vm_end和vma->vm_start的值从未检查有效性。取而代之的，它们被直接传递给remap_pfn_range作为尺寸参数。

这意味着一个恶意进程可以用一个不受限的尺寸来调用mmap。在我们这里，允许一个用户空间进程去mmap所有的在filp->private_databuffer之后的物理内存地址空间。这包括所有的内核内存。这意味着恶意进程能够从用户空间读写整个内核内存。

另一个流行的用法如下：

static int simple_mmap(struct file *filp, struct vm_area_struct *vma)
{
  printk(KERN_INFO "MWR: Device mmap\n");
  if ( remap_pfn_range( vma, vma->vm_start, vma->vm_pgoff, vma->vm_end - vma->vm_start, vma->vm_page_prot ) )
  {
    printk(KERN_INFO "MWR: Device mmap failed\n");
    return -EAGAIN;
  }
  printk(KERN_INFO "MWR: Device mmap OK\n");
  return 0;
}

上面的代码中我们可以看到用户控制的offset vma->vm_pgoff被直接传递给了remap_pfn_range函数作为物理地址。这会使得恶意进程有能力传递一个任意物理地址给mmap，也就在用户空间拥有了整个内核内存的访问权限。在一些对示例进行微小改动的情景中经常可以看到，要么offset有了掩码，要么使用了另外一个值来计算。

3.2 整数溢出

经常可以看到开发者试图使用复杂的计算、按位掩码、位移、尺寸和偏移和等方法去验证映射的尺寸和偏移(size and offset)。

不幸的是，这常常导致了创建的复杂性以及不寻常的计算和验证过程晦涩难懂。

在对size和offset值进行少量fuzzing后，找到可以绕过有效性检查的值并非不可能。

让我们看看这段代码：

static int integer_overflow_mmap(struct file *filp, struct vm_area_struct *vma)
{
  unsigned int vma_size = vma->vm_end - vma->vm_start;
  unsigned int offset = vma->vm_pgoff << PAGE_SHIFT;
  printk(KERN_INFO "MWR: Device integer_overflow_mmap( vma_size: %x, offset: %x)\n", vma_size, offset);
  if (vma_size + offset > 0x10000)
  {
    printk(KERN_INFO "MWR: mmap failed, requested too large a chunk of memory\n");
    return -EAGAIN;
  }
  if (remap_pfn_range(vma, vma->vm_start, virt_to_pfn(filp->private_data), vma_size, vma->vm_page_prot))
  {
    printk(KERN_INFO "MWR: Device integer_overflow_mmap failed\n");
    return -EAGAIN;
  }
  printk(KERN_INFO "MWR: Device integer_overflow_mmap OK\n");
  return 0;
}

上面的代码展示了一个典型的整数溢出漏洞，它发生在一个进程调用mmap2系统调用时使用了size为0xfffa000以及offset为0xf0006的情况。0xfffa000和0xf0006000的和等于0x100000000。

由于最大的unsigned int值为0xffffffff，最高符号位会被清掉，最终的和会变成0x0。这种情况下，mmap系统调用会成功绕过检查，进程会访问到预期buffer外的内存。

如上文提到的，有两个独立的系统调用mmap和mmap2。mmap2使得应用程序可以使用一个32位的off_t类型来映射大文件（最大为2^44字节），这是通过支持使用一个大数offset参数实现的。

有趣的是mmap2系统调用通常在64位内核系统调用表中不可用。然而，如果操作系统同时支持32位和64位进程，他就通常在32位进程中可用。这是因为32位和64位进程各使用独立的系统调用表。

3.3 有符号整型类型

另一个老生常谈的议题就是size变量的有符号类型。让我们看看这段代码：

static int signed_integer_mmap(
struct file *filp, struct vm_area_struct *vma)
{
  int vma_size = vma->vm_end - vma->vm_start;
  int offset = vma->vm_pgoff << PAGE_SHIFT;
  printk(KERN_INFO "MWR: Device signed_integer_mmap( vma_size: %x, offset: %x)\n", vma_size, offset);
  if (vma_size > 0x10000 || offset < 0 || offset > 0x1000 || (vma_size + offset > 0x10000))
  {
    printk(KERN_INFO "MWR: mmap failed, requested too large a chunk of memory\n");
    return -EAGAIN;
  }
  if (remap_pfn_range(vma, vma->vm_start, offset, vma->vm_end - vma->vm_start, vma->vm_page_prot))
  {
    printk(KERN_INFO "MWR: Device signed_integer_mmap failed\n");
    return -EAGAIN;
  }
  printk(KERN_INFO "MWR: Device signed_integer_mmap OK\n");
  return 0;
}

上述代码中，用户控制数据存储在vma_size和offset变量中，它们都是有符号整型。size和offset检查是这一行：

if (vma_size > 0x10000 || offset < 0 || offset > 0x1000 || (vma_size + offset > 0x10000))

不幸的是，因为vma_size被声明为有符号整型数，一种攻击手法是通过使用负数诸如0xf0000000来绕过这个检查。这回引起0xf0000000字节被映射到用户空间地址。

本文由看雪论坛玉涵编译，来源exploit-database-papers

转载请注明来自看雪社区

热门阅读

点击阅读原文/read，

更多干货等着你~

bxrf的瓜

失信被执行人的孩子上学受影响吗？最高法明确：受限！

”FAN某”的离婚财产分割判决书（全文）

”FAN某”的离婚财产分割判决书（全文）

公益慈善｜“翼行天下一生守护”慈善项目捐赠仪式圆满举行！