CVE-2014-4113的想法

作者: HopeBsod | 来源:发表于2019-05-31 17:56 被阅读0次

CVE-2014-4113的想法
关于想法的想法
没想法的想法
72 关于想法的想法
颠覆你想法的想法
大脑的想法，我的想法
想法与“想法”
想法只是想法
想法只是想法
想法只是想法

近期我想从事win32k的漏洞挖掘分析了些漏洞，从这个漏洞我考虑的是怎么发现的呢，
我对这块比较陌生，我熟悉的是DirectX这块的漏洞挖掘。
SetWindowsHookExA挂钩，TrackPopupMenu显示快捷菜单，poc是截获1EB消息。然后EndMenu 返回-5 为什么这样是因为xxxMNFindWindowFromPoint的返回值叫做v1吧他的返回判断是下面这样

    v38 = xxxMNFindWindowFromPoint((WCHAR)v3, (int)&UnicodeString, (int)v7);
    if ( !v38 && !UnicodeString )
    {
      xxxMNDismiss(a2);
      return 1;
    }
    if ( *(_BYTE *)v3 & 2 && v38 == -5 )  //与2其与-5比较
    {
      xxxMNSwitchToAlternateMenu(v3);
      v38 = -1;
    }
    if ( v38 == -1 )//与-1比较
    {
      xxxMNDoubleClick(a2, v3, UnicodeString);
      return 1;
    }
    v46 = *((_DWORD *)gptiCurrent + 45);
    *((_DWORD *)gptiCurrent + 45) = &v46;
    v47 = v38;
    if ( v38 )
      ++*(_DWORD *)(v38 + 4);
    v41 = UnicodeString;
    LOBYTE(v40) = -15;
    v39 = (void *)v38;
  LABEL_144:
      xxxSendMessage(v39, v40, v41, 0);  //xxxMNFindWindowFromPoint 的返回值接着被发送
  LABEL_145:
         ThreadUnlock1();
         return 1;

调用路径 NtUserTrackPopupMenuEx->xxxTrackPopupMenuEx->xxxMNLoop->xxxHandleMenuMessages->xxxMNFindWindowFromPoint->xxxSendMessage

因为对0xFFFFFFFB单独判断查看反汇编得知0xFFFFFFFFB被xxxSendMessage当作消息发送即bsod 如果0xFFFFFFFFB被申请则会被利用。下面是汇编 eax即是0xFFFFFFFFB

 .text:BF93935E                 test    byte ptr [edi], 2
 .text:BF939361                 jz      short loc_BF939371
 .text:BF939363                 cmp     eax, 0FFFFFFFBh
 .text:BF939366                 jnz     short loc_BF939371
 .text:BF939368                 push    edi             ; HDC
 .text:BF939369                 call    _xxxMNSwitchToAlternateMenu@4 ; xxxMNSwitchToAlternateMenu(x)
 .text:BF93936E                 or      eax, 0FFFFFFFFh
 .text:BF939371
 .text:BF939371 loc_BF939371:                           ; CODE XREF: xxxHandleMenuMessages(x,x,x)+5E9�j
.text:BF939371                                         ; xxxHandleMenuMessages(x,x,x)+5EE�j
 .text:BF939371                 cmp     eax, 0FFFFFFFFh
  .text:BF939374                 jnz     short loc_BF939382
 .text:BF939376                 push    dword ptr [ebp+UnicodeString]
  .text:BF939379                 push    edi
  .text:BF93937A                 push    esi
  .text:BF93937B                 call    _xxxMNDoubleClick@12 ; xxxMNDoubleClick(x,x,x)
 .text:BF939380                 jmp     short loc_BF9393B7

 .text:BF939382 loc_BF939382:                           ; CODE XREF: xxxHandleMenuMessages(x,x,x)+5FC�j
.text:BF939382                 mov     ecx, _gptiCurrent
 .text:BF939388                 add     ecx, 0B4h
 .text:BF93938E                 mov     edx, [ecx]
.text:BF939390                 mov     [ebp+var_20], edx
 .text:BF939393                 lea     edx, [ebp+var_20]
 .text:BF939396                 mov     [ecx], edx
 .text:BF939398                 mov     [ebp+var_1C], eax
 .text:BF93939B                 test    eax, eax
  .text:BF93939D                 jz      short loc_BF9393A2
 .text:BF93939F                 inc     dword ptr [eax+4]
  .text:BF9393A2
  .text:BF9393A2 loc_BF9393A2:                           ; CODE XREF: xxxHandleMenuMessages(x,x,x)+625�j
 .text:BF9393A2                 push    0               ; Address
   .text:BF9393A4                 push    dword ptr [ebp+UnicodeString] ; UnicodeString
  .text:BF9393A7                 push    1F1h            ; MbString
  .text:BF9393AC                 push    eax             ; P
  .text:BF9393AD
  .text:BF9393AD loc_BF9393AD:                           ; CODE XREF: xxxHandleMenuMessages(x,x,x)+172�j
 .text:BF9393AD                 call    _xxxSendMessage@16 ; xxxSendMessage(x,x,x,x)

.text:BF9393B2
对于挖掘如果看到这里发现对于-5没有单独判断，可以尝试挂钩处理会有收获。
fuzz呢？我对于fuzz说起来也就是for循环，加一些自己的小想法，这种漏洞我觉得发现者可能是看出来的，我之前也看出来过一个Directx的漏洞，但是刚看出来人家就补了蛮遗憾。这个漏洞的分析有现成poc打断点调试即可，至于怎么发现类似的我想是注意返回比较，看吧当然要熟悉menu的很多内容比如结构体，所以我决定在调试几个就再看文档整理成册然后先调调函数其他的再说