UAF原理与利用

0x00 UAF原理

 

如上代码所示，指针p1申请内存，打印其地址，值

然后释放p1

指针p2申请同样大小的内存，打印p2的地址，p1指针指向的值

Gcc编译，运行结果如下：

 

p1与p2地址相同，p1指针释放后，p2申请相同的大小的内存，操作系统会将之前给p1的地址分配给p2，修改p2的值，p1也被修改了。

由此我们可以知道：

1.在free一块内存后，接着申请大小相同的一块内存，操作系统会将刚刚free掉的内存再次分配。

根本原因是dllmalloc：

参考资料：http://blog.csdn.net/ycnian/article/details/12971863

当应用程序调用free()释放内存时，如果内存块小于256kb，dlmalloc并不马上将内存块释放回内存，而是将内存块标记为空闲状态。这么做的原因有两个：一是内存块不一定能马上释放会内核（比如内存块不是位于堆顶端），二是供应用程序下次申请内存使用（这是主要原因）。当dlmalloc中空闲内存量达到一定值时dlmalloc才将空闲内存释放会内核。如果应用程序申请的内存大于256kb，dlmalloc调用mmap()向内核申请一块内存，返回返还给应用程序使用。如果应用程序释放的内存大于256kb，dlmalloc马上调用munmap()释放内存。dlmalloc不会缓存大于256kb的内存块，因为这样的内存块太大了，最好不要长期占用这么大的内存资源。

 

2.通过p2能够操作p1，如果之后p1继续被使用（use after free），则可以达到通过p2修改程序功能等目的。

 

0x01 一个利用场景

在网上找了一个有UAF漏洞的ctf程序，参考博客如下：

http://www.syjzwjj.com/use-after-free-tutorial/

作者已经分析的很详细了，通过对整个程序的调试，来理解UAF的利用。

1.       结合IDA与程序运行，简要理解程序的功能。

 

选择1可以留言，信息会存到1个链表中

选择2将会遍历链表找到对应的节点，打印节点信息

打印完，可以对其进行删除修改等操作

 

链表节点结构如下

 

Tips：在逆向代码中应用数据结构参考《IDA Pro权威指南》第8章数据类型与数据结构

 2.       UAF漏洞代码

 

链表节点被删除后，可以继续进入modify函数，modify函数之后可以继续进入modify函数。

Delete函数如下：

 

Delete函数中对节点的进行了free操作，如果在循环代码中，进行delete操作，释放节点之后，再选择2进入modify函数。

Modify函数如下：

 

Modify函数从用户读取数据，然后拷贝到对应的指针中，但此时使用的是一个已经释放的指针。当输入content时，会取content的长度作为大小分配内存，当分配内存大小等于msg结构大小（48字节，通过前面的结构获得）时，会将刚才释放的内存分配给content指针。

如下所示

 

Content指向了msg结构本身

 

接着将content拷贝到content指针中，即我们的输入会拷贝到这个被释放的节点内存中。

 

在循环代码中，modify完之后可以继续进入modify。 此时会再对msg结构的author，title，content指针指向的地址进行拷贝。 由于上一步已经能够对msg结构进行随意更改了，所以将几个memcpy的目的地址修改成想要的地址即可进行任意内存（属于该程序的合法内存）的修改了。

 

至此我们已经能够完成任意内存地址的修改了。

下面需要考虑的就是完成一些命令执行的利用。

3.       漏洞利用执行命令

要执行命令，需要调用system函数，但是代码中并没有system函数，需要如何完成命令执行呢？

可以利用linux的延迟加载功能，改变strlen函数的指向，将原本要执行的strlen，改成执行system。

Tips：延迟加载

当调用标准函数时，需要从其他so文件中将标准函数加载进来，并不直接调用函数的地址，而是通过一张中间表跳转到函数的真正地址。

以strlen函数的调用为例

 

 

在程序调试中，打印0x804c04c的信息

 

整个过程如下：

Call strlen跳转到strlen函数，里面只有一句jmp ds：off_804c04c

当程序运行起来时0x804c04c里的值为0xb7658210，才是strlen的真正地址

即0x804c04c中存储libc库中的strlen的真正地址。

 

如果将0x804c04c的值改掉，改成system的地址0xb7614360。 虽然看起来调用的是strlen，但真正执行的是system函数。

修改前：

Call strlen  

                    Strlen:

                            Jmp 0x804c04c

                                                         0x804c04c: 0xb7658210(strlen)

 

修改后：

Call strlen  

                    Strlen:

                            Jmp 0x804c04c

                                                         0x804c04c: 0xb7614360 (system)

 

Tips: 寻址system的真正地址

由于整个程序并没有调用system函数，所以在程序的重定位表中找不到system。 所以需要自己定位一下system在这个程序中的真正地址。

 

Libc被装到0xb75d6000-0xb777a000 地址空间，大小为0x1a4000

编写程序调用system函数

 

调试运行查看其libc地址空间

 

被装入到0xb7e10000-0xb7fb4000,大小也为0x1a4000。

所以system在漏洞程序中的地址应为 =（system在调用程序中的地址-调用程序libc起始地址+漏洞程序libc起始地址）

 

0xb7e4e360

System在漏洞程序中地址= 0xb7e4e360-0xb7e10000+0xb75d6000= 0xb7614360

 4.       poc运行效果

执行一个mkdir hack命令建立一个hack目录

Poc片段

 

5.       过程回顾

1）  delete函数中释放节点

2）  modify函数传入被释放的指针

3）  modify函数中分配内存大小可控，通过分配与节点相同的大小，取得被释放内存的控制权

4）  修改将要被拷贝的目的地址msg->author指针指向将要被执行的函数strlen的中间表地址

5）  将strlen指向的真实strlen地址，修改为system的真实地址

6）  看似执行call strlen，实则执行了system函数

 

0x02 总结

在指针释放后再申请相同大小的内存，系统会将释放的地址进行分配，以提高系统运行速度，因此可以修改到被释放的内存数据，如果被释放的指针继续被使用，则会造成UAF漏洞。

通过UAF漏洞，可能可以造成一些任意内存的修改，结合代码特点，可能会造成任意内存的读取或者，严重的能够造成任意命令的执行，获得shell。 取决于被释放的指针是怎么使用的。

相关知识点：gdb调试（如何调试fork出来的程序），延迟加载（plt与got），标准函数在内存中的定位，UAF修改被释放指针内容的原因dllmalloc