背景

之前一直觉得root很神秘，这次尝试调试一下。对于我这样的菜鸟来说，刚开始还是调试一下比较老的洞吧，找啊找啊找漏洞，找到了CVE-2014-0038，因为看了几篇分析的文章发现大概能看懂(苦笑~能看懂真的不容易)

出现问题的函数是下面这个函数：

这个函数直接接收用户态传入的timeout指针,并且根据一定的条件可以修改timeout指向变量的值.这就造成了内核任意地址写的漏洞。如果利用这个漏洞修改某个内核函数指针,让它指向用户态的地址,在用户态的地址放上提权代码，这样等下次调用这个函数的时候，就可以以内核的模式来执行提权代码。

根据exploit-db的代码运行一下：

接着试着调试一下这个exploit，调试linux内核，用的是kgdb+vmware+com。(虽然网上有不少设置的教程但还是遇到不少坑)

调试

编译完内核之后，一些内核参数地址发生改变，修改为以下。

gdb通过串口连接目标机，触发漏洞的函数是__sys_recvmmsg，下个断点

break __sys_recvmmsg

continue

开机，运行./poc

gdb 中断在了__sys_recvmmsg

根据poc，要想成功的利用就要把 0xffffffff81a93500 -> 0xffffffff816acaf0  修改成 0xffffffff81a93500 -> 0x000000ff816acaf0 就是修改net_ctl_permissions函数指针为用户态的地址。

看一下timeout的地址和值，和0xffffffff81a9350地址的值

0xffffffff81a93500 -> 0xffffffff816acaf0  (正常情况net_ctl_permissions的值)

timeout: 

0xffffffff81a93507 -> 0xff                        (0xffffffff816acaf0最高的8位)

对应的tv_sec=255 tv_nsec=0

最后想办法让

0xffffffff81a93507 -> 0x00

0xffffffff81a93506 -> 0x00

0xffffffff81a93505 -> 0x00

不就可以使 0xffffffff81a93500 -> 0x000000ff816acaf0 了吗，exploit也确实是这么做的。

接着看一看 0xff 是如何变成 0x00的

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