solid_core出题时候，基本上是以CSAW-2015-CTF的stringipc题目为基础进行内存读写的限制，CSAW-2015-CTF中的题目是一个krealloc的利用。
在krealloc的定义中mm/slab_common.c中

如果size=0,krealloc返回值为0x10

通过修改size=-1,使得kremalloc的返回值变成0x10,同时size因为是0xFFFFFFFFFFFFFFFF所以可以进行任意地址读写。

那么传统思路下一步提权的方法有两种，下面进行介绍。

下面以csaw-2015的stringipc为例子来介绍两种从任意地址读写到权限提升到权限的传统思路

做过内核漏洞利用的同学应该都了解task_struct中的cred结构代表了该进程的权限结构。

如果我们能够修改cred结构的值那么就可以进行提权操作。这是一个很正常的思路，但是我们的cred结构地址在哪里呢？这里CSAW给出的思路是通过prctl设置comm结构为一个Random的字符串是，然后通过爆破这个Random的字符串，每八个字节进行遍历，耗时比较久，但是是可行的。
链接如下 https://github.com/mncoppola/StringIPC/blob/master/solution/solution.c

第二种方法是使用RET2DIR攻击，在这里CSAW-2015-stringipc可以通过攻击VDSO来劫持用户态的代码执行流程。下面我们先来补充一下VDSO的知识：

VDSO(Virtual Dynamically-linked Shared Object)是个很有意思的东西, 它将内核态的调用映射到用户态的地址空间中, 使得调用开销更小, 路径更好.

开销更小比较容易理解, 那么路径更好指的是什么呢? 拿x86下的系统调用举例, 传统的int 0x80有点慢, Intel和AMD分别实现了sysenter, sysexit和syscall, sysret, 即所谓的快速系统调用指令, 使用它们更快, 但是也带来了兼容性的问题. 于是Linux实现了vsyscall, 程序统一调用vsyscall, 具体的选择由内核来决定. 而vsyscall的实现就在VDSO中.

Linux(kernel 2.6 or upper)环境下执行ldd /bin/sh, 会发现有个名字叫linux-vdso.so.1(老点的版本是linux-gate.so.1)的动态文件, 而系统中却找不到它, 它就是VDSO. 例如:

所以，不难理解，VDSO是一段内核空间的代码，用来提供给用户态下更快地调用系统调用。正是因为这个特殊的机制，使得我们可以进行攻击。
在CSAW-CTF-2015的stringipc题目中，内核态下VDSO页的权限是RW，这个代码页会被直接映射到用户态下的进程中，以满足gettime等频繁系统调用的速度。这个代码页映射到用户态的权限属性是RX，就是可以执行。所以，我们可以通过在内核态下通过任意写来修改VDSO的代码，譬如我们修改代码成为prepare_cred+commited_cred等，这样在用户调用VDSO时，就可以劫持控制流了。
具体链接如下: http://itszn.com/blog/?p=21

这里也有一个问题:VDSO位置在哪里呢？这个可以爆破，因为我们有了任意地址读的权限，不过和上面爆破cred结构的技术不一样，我们可以更快的爆破，因为VDSO必定是被安防到一个内存页里面，也就是页对其的，同时它是一个ELF文件，是有ELF Signurte，所以我们可以按照内存页的偏移来进行爆破，这样爆破速度会很快，大概是256倍,而且它的映射位置离内核基址并不是太远，可以很快就出来了。

题目为了限制大家不能使用cred覆盖和ret2dir攻击利用方法，我对csaw-ctf-2015进行了修改，限制了内存读写范围。

我进行了限制，限制写入范围必须大于0xffffffff80000000，这个地址在linux内存分布中，是kernel base以上。
附上linux 内核内存分布图

所以可以限制cred被覆盖，同时编译最新内核以限制VDSO在内核情况下不能被修改。

可以使得上两种的利用方法失效，以期待有高手能够给出一种另外的利用思路，同时我也给出了一种限制之后可以成功利用思路，也就是HijackPrctl，下面进行详细介绍。

下面介绍从内核地址任意读写(或者可以限制为局部地址读写)到任意代码执行的一种新型的Reliable Linux Root技术，这个思路其实也不算最新的，是来自于INetCop Security 分享的New Reliable Android Kernel Root Exploitation Techniques,这种漏洞利用思路主要是要劫持Prctl函数，最后跳转到call_usermodehelper,我姑且把这种方法称作HijackPrctl。
我们再来确定一下现在能做的事情,我们可以进行局部地址的任意读写，题目限制了读写范围必须大于0xffffffff80000也就是kernel base以上。为了达到代码执行，我们先找一个内核函数看能不能劫持的。

这里要介绍一下Prctl函数，这个函数可以对进程进行一些设置，通过查看linux内核源码，可以知道这个函数是一个内核漏洞利用中的绝佳函数。
在include/linux/security.h中可以看到cap_task_prctl拥有6个参数。

同时在kernel/sys.c中，可以看到对于prctl这个系统调用的处理过程中，将参数原封不动的传给了security_task_prctl函数进行处理。

继续往下跟进，我们发现security_task_prctl这个函数其实最后是定位到了一个虚表里面去，

在调试时候我们会找到这个hook的位置在哪里，在这里是capability+0x520+0x18这个偏移，这个偏移在IDA中也能分析出来。

这样的话，我们就找到了一个可以通过用户态传最多6个参数并且到内核态原封不动执行的虚函数。也就是意味我们可以通过修改这个指针，可以任意执行一个函数了。

基于上面的分析我们可以通过用户态传递参数，在内核态下任意执行6个参数以下的函数。再仔细分析一下，对吗？在32位下是可以的，在64位下并不是。我们再看这个函数
int security_task_prctl(int option, unsigned long ...)发现第一个参数option是int类型，也就是我们传入的64位会被截断成为32位，这也就导致了64位，第一个参数不能用了。
这个不影响32位下的漏洞利用，我们继续来分析32位如何利用。
其实，这里有很多思路，INetCop Security的Slide里面有，我这里介绍另外一种基于VDSO变形的方法，也是看雪论坛上(https://bbs.pediy.com/thread-220057.htm)，提出的一种方法。
具体思路是:

call_usermoderhelper是内核运行用户程序的一个api,并且该程序有root的权限。如果我们能够控制性的调用它，就能以Root权限执行我们想要执行的程序了。
定义在kernel/umh.c中

subprocess_info如下

我们要劫持task_prctl到call_usermoderhelper吗，不是的，因为这里的第一个参数也是64位的，也不能直接劫持过来。但是内核中有些代码片段是调用了Call_usermoderhelper的，可以转化为我们所用。
譬如kernel/reboot.c中的orderly_poweroff函数中调用了run_cmd参数是poweroff_cmd,而且poweroff_cmd是一个全局变量，可以修改。

那么我们就先篡改poweroff_cmd=我们预期执行的命令，然后直接劫持task_prctl到orderly_poweroff函数，这样就任意命令执行了，同时按照INetCop Security给出的思路，需要先关闭selinux。

所以再整理一下整体思路:

很惨，出题时候由于一些设置问题，产生了一些的非预期解(一共有5只队伍解出题目，三只使用非预期解，两只使用正解)，不过这些非预期解也让我学习到了很多知识(姿势)。
同时在题目部署中也出现了一些问题，但是因为已经出现了非预期解，保持题目公平性，所以也就没有进行继续修改了。
同时在出这道题目的过程中，多次对内核进行编译，对于很多以前不知道的内核知识进行补充，踩了很多坑，也学了很多。
最后祝贺做出此题的战队以及参与强网杯比赛的各位战队，希望能够和各位大神继续交流内核漏洞相关的知识。
同时最近出现的ubuntu16.04提权漏洞也是一个任意内存读写漏洞，理论上也能够使用该种方法进行提权，下面我会抽时间进行调试并分析。
如果大家还想继续做这道题目的话，题目继续在10.9.173.101 9999开放。
同时本文也在本人博客上面进行发表。http://leanote.com/blog/post/5ab78270ab64413755000dcf

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课