内核和驱动学习方法（内核驱动mmapHandler利用技术）

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 "s:" softirq_to_name[i]);

for_each_possible_cpu(j)

seq_printf(p " u" 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");

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转载请注明来自看雪社区