首页
社区
课程
招聘
问答 CTF 排行榜 知识库 工具下载 峰会 看雪商城 证书查询
  1. 社区
  2. 二进制漏洞
    3. 发新帖
[讨论]关于“安全漏洞本质扯谈之决战汇编代码”文中示例的理解
发表于: 2015-3-8 02:45 3550

[讨论]关于“安全漏洞本质扯谈之决战汇编代码”文中示例的理解

Chenlgen 活跃值
1
2015-3-8 02:45
3550
0x00 前言
看了wooyun上的一篇帖子“安全漏洞本质扯谈之决战汇编代码”，觉得里面一些存在漏洞的代码例子还不错，下面对里面的示例存在的问题进行个人的分析，比较浅显，不到之处还请指出来，有些例子我也不知道问题在哪

0x01 源代码层面的例子
1. Link Attack
*unix 下的 link attack,有意识到吗？

1
2
3
4
5
6
if(access("file",W_OK)!=0){
    exit(1);
}
fd = open("file",O_WRONLY);
  
write(fd,buffer,sizeof(buffer));

仔细看了下access函数的用法，其中有一条警告：access() always dereferences symbolic links. If you need to check the permissions on a symbolic link, use faccessat(2) with the flag AT_SYMLINK_NOFOLLOW.
意思是access函数总是会接引用符号链接，如果需要检查符号链接本身的权限，请使用faccessat替代。
也就是说如果“file”是一个符号链接的话，access检查的并不是符号链接本身，检查被绕过。不知道对不对，还请大牛们解答。

2. Integer Overflow Example in OpenSSH 3.1
发生在真实的 openssh 3.1 ，有漏洞吗？
1
2
3
4
5
6
7
8
9
u_int nresp;
...
nresp = packet_get_int();
if(nresp){
    response = xmalloc(nresp * sizeof(char*));
    for(i=0; i<nresp; i++)
        response[i] = packet_get_string(NULL);
}
packet_check_eom();

这个是典型的integer overflow，xmalloc函数形式为void *xmalloc(size_t bytes)，参数bytes是size_t，是无符号的。上例中nresp*sizeof(char *)在ILP32系统下相当nresp*4，明显会溢出，造成分配的内存远小于预期值。当nresp*4<nresp时，response[i] = packet_get_string(NULL)将进一步引发内存溢出。

3. Signed Integer Vulnerability Example
注意整形符号，能被绕过吗？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
int read_user_data(int sockfd) 
{
   int length, sockfd, n;
   char buffer[1024];
  
   length = get_user_length(sockfd);
  
   if(length > 1024){
       error("illegal input, not enough room in buffer\n"); 
       return 1;
   }
  
   if(read(sockfd, buffer, length) < 0){ error("read: %m");
       return 1;
   }
  
   return 0; 
}

这个是典型的无符号与有符号滥用引发的问题，length为int型，当length<0时，显然可以通过length>1024的检查。而后续又调用了read(sockfd, buffer, length)，read函数的第三个参数类型为size_t类型是无符号的，length<0时，即表示的无符号值>0x80000000，造成读取的数据长度远超过1024，进而引发栈溢出。

4. Truncation Vulnerability Example in NFS
整形截断问题？

1
2
3
4
5
6
7
8
9
10
11
void assume_privs(unsigned short uid) {
   seteuid(uid);
   setuid(uid);
}
  
int become_user(int uid) 
{
   if (uid == 0)
       die("root isnt allowed");
   assume_privs(uid); 
}

典型的整形截断问题，uid是int型，而函数assume_privs接受的参数uid为unsigned short，int转化为unsigend short发生截断，而且还存在符号问题。

5. 苹果SSL/TLS 重大安全漏洞的细节
(CVE-2014-1266)多个goto fail造成重大安全隐患。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
    ...
  
    if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;  <---- *** DANGER ***
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
        goto fail;
  
        err = sslRawVerify(ctx,
                       ctx->peerPubKey,
                       dataToSign,                              /* plaintext */
                       dataToSignLen,                   /* plaintext length */
                       signature,
                       signatureLen);
    ...
fail:
    SSLFreeBuffer(&signedHashes);
    SSLFreeBuffer(&hashCtx);
    return err;
  
}

这里就是    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;  <---- *** DANGER ***
多了一个goto fail，相当于只要到了if(err = ssl...)这条语句，无论条件是否成立，都会goto fail。

6. MS-RPC DCOM Buffer Overflow
(冲击波)
冲击波蠕虫只因为一个缓冲区溢出。
1
2
3
4
5
6
7
8
HRESULT GetMachineName (WCHAR * pwszPath) {
     The WCHAR wszMachineName [N + 1]); 
     ...
     LPWSTR pwszServerName = wszMachineName;
     while (* pwszPath! = L '\\')
         * PwszServerName + + = * pwszPath + +;   
     ...
 }

典型的栈溢出，wszMachineName[N+1]固定buffer大小为N+1，后续对wszMachineName这个buffer进行写入时，完全没有长度检查， "* PwszServerName + + = * pwszPath + +“语句不断对buffer进行写入直到*pwszPath != L'\\'，比如文件路径名为'A'*N*2+L'\\'，则造成溢出。

7. 有漏洞吗？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
unsigned short read_length(int sockfd) 
{
    unsigned short len;
  
    if(full_read(sockfd, (void *)&len, 2) != 2)
        die("could not read length!\n");
    return ntohs(len);
}
  
int read_packet(int sockfd) 
{
   struct header hdr;
   short length;
   char *buffer;
  
   length = read_length(sockfd);
  
   if(length > 1024){
       error("read_packet: length too large: %d\n", length); 
       return 1;
   }
  
   buffer = (char *)malloc(length+1);
  
   if((n = read(sockfd, buffer, length) < 0){
       error("read: %m");
       free(buffer);
       return 1;
   }
   buffer[n] = '\0';
   return 0; 
}

这个又是无符号与有符号滥用的问题，read_length返回的unsigned short型，然后返回结果又short型的length接收，当read_length返回值大于0x8000时，后续的if length>1024的检查将被飘过。。。当length=-1，即0xffff时，malloc(length+1) <-> malloc(0)，又是各种溢出。

8. 有漏洞吗？
提示: 5rOo5oSPc216ZW9m
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
char *read_username(int sockfd) 
{
    char *buffer, *style, userstring[1024]; 
    int i;
  
    buffer = (char *)malloc(1024);
  
    if(!buffer){
        error("buffer allocation failed: %m"); 
        return NULL;
    }
  
    if(read(sockfd, userstring, sizeof(userstring)-1) <= 0){ 
       free(buffer);
       error("read failure: %m");
       return NULL;
    }
  
    userstring[sizeof(userstring)-1] = '\0';
  
    style = strchr(userstring, ':'); 
    if(style)
       *style++ = '\0';
  
    sprintf(buffer, "username=%.32s", userstring);
  
    if(style)
        snprintf(buffer, sizeof(buffer)-strlen(buffer)-1,
                 ", style=%s\n", style);
    return buffer;
}

buffer和userstring大小均为1024，语句sprintf(buffer, "username=%.32s", userstring)明显会引发buffer溢出。。。

9. 有漏洞吗？
提示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
enter image description here
/* special thing for ldap.
* The parts are separated by question marks. 
* From RFC 2255:
* ldapurl = scheme "://" [hostport] ["/"
*           [dn ["?" [attributes] ["?" [scope] 
*           ["?" [filter] ["?" extensions]]]]]]
*/
  
if (!strncasecmp(uri, "ldap", 4)) 
{
    char *token[5];
    int c = 0;
  
    token[0] = cp = ap_pstrdup(p, cp); 
    while (*cp && c < 5) {
        if (*cp == '?') {
            token[++c] = cp + 1;
            *cp = '\0';
        }
        ++cp; 
    }

while循环的判定*cp && c<5，当c=4，*(cp+4) == ‘?'时，token[++c] = cp+1语句即为token[5] = cp + 1，溢出了啊~~

10. 有漏洞吗？(Antisniff v1.1 Vulnerability)
tips
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
char *indx;
int count;
char nameStr[MAX_LEN]; //256
...
memset(nameStr, '\0', sizeof(nameStr));
...
indx = (char *)(pkt + rr_offset); 
count = (char)*indx;
  
while (count){
    if (strlen(nameStr) + count < ( MAX_LEN - 1) ){
       (char *)indx++;
       strncat(nameStr, (char *)indx, count); 
       indx += count;
       count = (char)*indx;
       strncat(nameStr, ".",
               sizeof(nameStr) strlen(nameStr));
    } else {
       fprintf(stderr, "Alert! Someone is attempting "
                       "to send LONG DNS packets\n");
       count = 0; }
}
nameStr[strlen(nameStr)-1] = '\0';

indx指向数据包pkt偏移为rr_offset的位置，count = (char)*indx语句即将indx指向的一字节值赋给count，关键就在count是int型，在ILP32 os下是4字节，count =(char)*indx语句会将*indx进行符号扩展到32位，对应的汇编语句为movsx。比如当*indx==0xff， 则count=0xffffffff。则当*indx>0x80时，count将<0。
while(count)只要count不为0则通过。而if (strlen(nameStr) + count < (MAX_LEN - 1))，由于count会有符号类型，虽然strlen返回的unsinged int，但无符号与有符号数运算，会提升为有符号运算，当count<0时，这个条件直接飘过。
之后strncat(nameStr, (char *)indx, count)，strncat的第三个参数为size_t，即将count解释为无符号的，即(unsigned int)count，此时明显将引发nameStr溢出。。
引发这个漏洞的关键就在count = (char)*indx语句，进行了有符号扩展！！！

11. 还有漏洞吗？(Antisniff v1.1.1 Vulnerability)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
char *indx;
int count;
char nameStr[MAX_LEN]; //256
...
memset(nameStr, '\0', sizeof(nameStr));
...
indx = (char *)(pkt + rr_offset); 
count = (char)*indx;
  
while (count){
/* typecast the strlen so we aren't dependent on 
  the call to be properly setting to unsigned. */
  
  if ((unsigned int)strlen(nameStr) + 
    (unsigned int)count < ( MAX_LEN - 1) ){
    (char *)indx++;
    strncat(nameStr, (char *)indx, count); 
    indx += count;
    count = (char)*indx;
    strncat(nameStr, ".",
            sizeof(nameStr) strlen(nameStr)); 
  } else {
    fprintf(stderr, "Alert! Someone is attempting "
                    "to send LONG DNS packets\n");
    count = 0; 
  }
}
nameStr[strlen(nameStr)-1] = '\0';

这个例子是在例11的基础上的更新版，但依然存在问题。
上面已经说了count = (char)*indx语句造成了有符号扩展，即使if判断语句修补之前的问题，但仍然没有解决问题。比如当count=0xffffffff时，(unsigned int)strlen(nameStr) +   (unsigned int)count也会造成无符号加法进位啊，所以<max_len -1很好满足啊！

12. 还有漏洞吗？(Antisniff v1.1.2 Vulnerability)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
unsigned char *indx;
unsigned int count;
unsigned char nameStr[MAX_LEN]; //256
...
memset(nameStr, '\0', sizeof(nameStr));
...
indx = (char *)(pkt + rr_offset); 
count = (char)*indx;
  
while (count){
    if (strlen(nameStr) + count < ( MAX_LEN - 1) ){ 
       indx++;
       strncat(nameStr, indx, count);
       indx += count;
       count = *indx;
       strncat(nameStr, ".",
               sizeof(nameStr) strlen(nameStr));
     } else {
       fprintf(stderr, "Alert! Someone is attempting "
                       "to send LONG DNS packets\n");
       count = 0; 
     }
}
nameStr[strlen(nameStr)-1] = '\0';

这个打补丁的man仍没弄清楚bug的症结所在，把count改为unsigned int完全没用啊，count = (char)*indx语句还是有符号扩展啊，还是movsx啊。。。

0x02 汇编代码层面

1. Safe or vulnerability?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
text:0040106B sub_40106B      proc near               ; CODE XREF: _main+58p
.text:0040106B
.text:0040106B var_10004       = byte ptr -10004h
.text:0040106B var_4           = dword ptr -4
.text:0040106B arg_0           = word ptr  8
.text:0040106B
.text:0040106B                 push    ebp
.text:0040106C                 mov     ebp, esp
.text:0040106E                 mov     eax, 10004h
.text:00401073                 call    __alloca_probe
.text:00401078                 mov     eax, dword_404020
.text:0040107D                 xor     eax, ebp
.text:0040107F                 mov     [ebp+var_4], eax
.text:00401082                 movsx   eax, [ebp+arg_0]
.text:00401086                 movsx   eax, [ebp+eax+var_10004]
.text:0040108E                 push    eax
.text:0040108F                 push    offset Format   ; "t %x"
.text:00401094                 call    ds:printf
.text:0040109A                 pop     ecx
.text:0040109B                 pop     ecx
.text:0040109C                 mov     ecx, [ebp+var_4]
.text:0040109F                 xor     ecx, ebp
.text:004010A1                 xor     eax, eax
.text:004010A3                 call    sub_401BD2
.text:004010A8                 leave

汇编的这个例子，跟前文源码的例11、12、13问题是一样的，00401082处的指令movsx eax, [ebp+arg_0]，对arg_0进行了有符号扩展，即只要传入参数arg_0<0，则eax<0，即eax>0x80000000，紧接着的movsx eax, [ebp+eax+var_10004]，ebp+eax将可以非常大，造成内存访问异常，甚至是任意地址读啊！！

2. Safe or vulnerability?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
text:004010AA sub_4010AA      proc near               ; CODE XREF: _main+60p
.text:004010AA
.text:004010AA var_190         = dword ptr -190h
.text:004010AA arg_0           = dword ptr  8
.text:004010AA
.text:004010AA                 push    ebp
.text:004010AB                 mov     ebp, esp
.text:004010AD                 mov     eax, [ebp+arg_0]
.text:004010B0                 sub     esp, 190h
.text:004010B6                 cmp     eax, 64h
.text:004010B9                 jle     short loc_4010BE
.text:004010BB                 push    64h
.text:004010BD                 pop     eax
.text:004010BE
.text:004010BE loc_4010BE:                             ; CODE XREF: sub_4010AA+Fj
.text:004010BE                 push    [ebp+eax*4+var_190]
.text:004010C5                 push    offset Format   ; "t %x"
.text:004010CA                 call    ds:printf
.text:004010D0                 pop     ecx

cmp eax, 64h，下面是jle即进行有符号比较，当eax>0x80000000时，即eax<0<64h，完成跳转，[ebp+eax*4+var_190]将引发内存访问异常。

3. Safe or vulnerability?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
.text:00401000 sub_401000      proc near               ; CODE XREF: _main+48p
.text:00401000
.text:00401000 var_190         = dword ptr -190h
.text:00401000 arg_0           = dword ptr  8
.text:00401000
.text:00401000                 push    ebp
.text:00401001                 mov     ebp, esp
.text:00401003                 mov     eax, [ebp+arg_0]
.text:00401006                 sub     esp, 190h
.text:0040100C                 cmp     eax, 64h
.text:0040100F                 jbe     short loc_401014
.text:00401011                 push    64h
.text:00401013                 pop     eax
.text:00401014
.text:00401014 loc_401014:                             ; CODE XREF: sub_401000+Fj
.text:00401014                 push    [ebp+eax*4+var_190]
.text:0040101B                 push    offset Format   ; "t %x"
.text:00401020                 call    ds:printf
.text:00401026                 pop     ecx
.text:00401027                 pop     ecx

例3将例2中jle改成了jbe即进行无符号比较，除了当arg_0==64h时，push [ebp+eax*4+var_190]，即push [ebp]，相当于printf原ebp外，没看到什么其他问题，还请各位大牛解惑啊~

4. Safe or vulnerability?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
.text:004010D6 sub_4010D6      proc near               ; CODE XREF: _main+68p
.text:004010D6
.text:004010D6 arg_0           = dword ptr  4
.text:004010D6
.text:004010D6                 push    esi
.text:004010D7                 push    64h             ; Size
.text:004010D9                 call    ds:malloc
.text:004010DF                 mov     esi, eax
.text:004010E1                 mov     eax, [esp+8+arg_0]
.text:004010E5                 cmp     eax, 64h
.text:004010E8                 pop     ecx
.text:004010E9                 jle     short loc_4010EE
.text:004010EB                 push    64h
.text:004010ED                 pop     eax
.text:004010EE
.text:004010EE loc_4010EE:                             ; CODE XREF: sub_4010D6+13j
.text:004010EE                 movsx   eax, byte ptr [eax+esi]
.text:004010F2                 push    eax
.text:004010F3                 push    offset Format   ; "t %x"
.text:004010F8                 call    ds:printf
.text:004010FE                 push    esi             ; Memory
.text:004010FF                 call    ds:free

例4与例2是一样的，cmp eax, 64h, jle有符号比较，movsx eax, byte ptr[eax+esi]将引发内存访问异常。

5. Safe or vulnerability?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
. text:0040110C sub_40110C      proc near               ; CODE XREF: _main+70p
.text:0040110C
.text:0040110C var_19A0        = byte ptr -19A0h
.text:0040110C var_4           = dword ptr -4
.text:0040110C arg_0           = word ptr  8
.text:0040110C
.text:0040110C                 push    ebp
.text:0040110D                 mov     ebp, esp
.text:0040110F                 mov     eax, 19A0h
.text:00401114                 call    __alloca_probe
.text:00401119                 mov     eax, dword_404020
.text:0040111E                 xor     eax, ebp
.text:00401120                 mov     [ebp+var_4], eax
.text:00401123                 movsx   eax, [ebp+arg_0]
.text:00401127                 movsx   eax, [ebp+eax+var_19A0]
.text:0040112F                 push    eax
.text:00401130                 push    offset Format   ; "t %x"
.text:00401135                 call    ds:printf
.text:0040113B                 pop     ecx
.text:0040113C                 pop     ecx
.text:0040113D                 mov     ecx, [ebp+var_4]
.text:00401140                 xor     ecx, ebp

例5跟上面一样，movsx eax, [ebp+arg_0]

6. Safe or vulnerability?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
.text:0040102C sub_40102C      proc near               ; CODE XREF: _main+50p
.text:0040102C
.text:0040102C var_10004       = byte ptr -10004h
.text:0040102C var_4           = dword ptr -4
.text:0040102C arg_0           = word ptr  8
.text:0040102C
.text:0040102C                 push    ebp
.text:0040102D                 mov     ebp, esp
.text:0040102F                 mov     eax, 10004h
.text:00401034                 call    __alloca_probe
.text:00401039                 mov     eax, dword_404020
.text:0040103E                 xor     eax, ebp
.text:00401040                 mov     [ebp+var_4], eax
.text:00401043                 movzx   eax, [ebp+arg_0]
.text:00401047                 movsx   eax, [ebp+eax+var_10004]
.text:0040104F                 push    eax
.text:00401050                 push    offset Format   ; "t %x"
.text:00401055                 call    ds:printf
.text:0040105B                 pop     ecx

例6将例5中movsx改成了 movzx   eax, [ebp+arg_0]，即不足的补0处理，除了没有对arg_0本身大小进行检查，其他没看出什么问题

7. Safe or vulnerability?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
. .text:0040118A ; int __cdecl sub_40118A(LPCSTR lpMultiByteStr)
.text:0040118A sub_40118A      proc near               ; CODE XREF: _main+91p
.text:0040118A
.text:0040118A WideCharStr     = word ptr -44h
.text:0040118A var_4           = dword ptr -4
.text:0040118A lpMultiByteStr  = dword ptr  8
.text:0040118A
.text:0040118A                 push    ebp
.text:0040118B                 mov     ebp, esp
.text:0040118D                 sub     esp, 44h
.text:00401190                 mov     eax, dword_404020
.text:00401195                 xor     eax, ebp
.text:00401197                 mov     [ebp+var_4], eax
.text:0040119A                 mov     ecx, [ebp+lpMultiByteStr]
.text:0040119D                 mov     eax, ecx
.text:0040119F                 push    esi
.text:004011A0                 lea     esi, [eax+1]
.text:004011A3
.text:004011A3 loc_4011A3:                             ; CODE XREF: sub_40118A+1Ej
.text:004011A3                 mov     dl, [eax]
.text:004011A5                 inc     eax
.text:004011A6                 test    dl, dl
.text:004011A8                 jnz     short loc_4011A3
.text:004011AA                 push    40h             ; cchWideChar
.text:004011AC                 lea     edx, [ebp+WideCharStr]
.text:004011AF                 push    edx             ; lpWideCharStr
.text:004011B0                 sub     eax, esi
.text:004011B2                 push    eax             ; cbMultiByte
.text:004011B3                 push    ecx             ; lpMultiByteStr
.text:004011B4                 push    0               ; dwFlags
.text:004011B6                 push    0               ; CodePage
.text:004011B8                 call    ds:MultiByteToWideChar

前面代码查找lpMultiByteStr指向字符串的'\0‘结束符，从而得出字符串的大小，即sub eax, esi，eax为字符串大小，但调用MultiByteToWideChar函数进行宽字符转换时，push 40h传入了固定大小的buffer，但又没有检查原字符串的大小是否超过40个字符，即当eax>40时，溢出。

8. Safe or vulnerability?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
text:00401738 Size            = dword ptr  4
.text:00401738 Src             = dword ptr  8
.text:00401738
.text:00401738                 push    esi
.text:00401739                 push    edi
.text:0040173A                 mov     edi, [esp+8+Size]
.text:0040173E                 lea     eax, [edi+1]
.text:00401741                 push    eax             ; Size
.text:00401742                 call    ds:__imp__malloc
.text:00401748                 mov     esi, eax
.text:0040174A                 test    esi, esi
.text:0040174C                 pop     ecx
.text:0040174D                 jz      short loc_401774
.text:0040174F                 push    edi             ; Size
.text:00401750                 push    [esp+0Ch+Src]   ; Src
.text:00401754                 push    esi             ; Dst
.text:00401755                 call    _memcpy
.text:0040175A                 push    esi
.text:0040175B                 push    offset aS       ; "%s\n"
.text:00401760                 mov     byte ptr [esi+edi], 0
.text:00401764                 call    ds:__imp__printf

代码块完成两个工作：malloc(Size+1)， memcpy。
问题就出在Size+1，当Size=0xffffffff时，Size+1=0，而malloc(0)的返回值并不为0，下面是msdn中对malloc的size参数为0时的解释：
If size is 0, malloc allocates a zero-length item in the heap and returns a valid pointer to that item. Always check the return from malloc, even if the amount of memory requested is small.
因此，test esi, esi, jz不会完成跳转，但此时malloc返回的内存大小为zero-length，往该内存区域memcpy经出现异常。


[注意]看雪招聘，专注安全领域的专业人才平台！

收藏
免费
支持
分享
最新回复 (3)
红颜世家、
雪    币： 1626
活跃值： (17)
能力值： ( LV2，RANK：10 )
在线值：
发帖
回帖
粉丝
私信
2 楼
虽然看不懂....不过膜拜大大...
2015-3-8 12:31
0
AJISky
雪    币： 269
活跃值： (906)
能力值： ( LV12，RANK：345 )
在线值：
发帖
回帖
粉丝
私信
3 楼
不做挖掘工作的coder，很容易写出各种漏洞的代码
2015-3-8 18:28
0
封心锁爱
雪    币： 239
活跃值： (10)
能力值： ( LV2，RANK：10 )
在线值：
发帖
回帖
粉丝
私信
4 楼
学了不少整数溢出和有符号, 无符号的知识.
2015-3-8 19:05
0
游客
登录 | 注册 方可回帖
回帖 表情 雪币赚取及消费
高级回复
返回

账号登录
验证码登录

忘记密码？
没有账号？立即免费注册
我已同意 《看雪服务条款》 《看雪课程免责声明》 《看雪隐私政策》