自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

SMBv3遠程拒絕服務(BSOD)漏洞分析

作者：k0shl
安全 漏洞
這個SMBv3漏洞是由lgandx爆出的一個未被微軟修復的漏洞（暫未發(fā)布補丁），漏洞出來后我進行了一定的分析。

[[183427]]

前言

這個SMBv3漏洞是由lgandx爆出的一個未被微軟修復的漏洞(暫未發(fā)布補丁)，漏洞出來后我進行了一定的分析，花了很多時間，這個漏洞有一些意思，但是對于SMB的整個協(xié)議通信過程非常龐大，所以沒有進行非常細致的跟蹤，包括一些不透明的結構體讓我感到暈頭轉向，但到最后還是有了一些結果。

這個SMB漏洞可以看作是被動的，需要用戶主動去訪問445端口才可以觸發(fā)，而不像ms08067一樣主動攻擊別人，所以需要運行漏洞腳本在操作系統(tǒng)上。

那么很多人看到PoC中的關鍵部分，就會想：有填充數(shù)據(jù)，會不會是緩沖區(qū)溢出!

  1. ## Tree Connect 
  2. if data[16:18] == "\x03\x00": 
  3. head = SMBv2Header(Cmd="\x03\x00", MessageId=GrabMessageID(data), PID="\xff\xfe\x00\x00", TID="\x01\x00\x00\x00", CreditCharge=GrabCreditCharged(data), Credits=GrabCreditRequested(data), NTStatus="\x00\x00\x00\x00", SessionID=GrabSessionID(data)) 
  4. t = SMB2TreeData(Data="C"*1500)#//BUG 
  5. packet1 = str(head)+str(t) 
  6. buffer1 = longueur(packet1)+packet1 
  7. print "[*]Triggering Bug; Tree Connect SMBv2 packet sent." 
  8. self.request.send(buffer1) 
  9. data = self.request.recv(1024) 

答案是否定的，至少在我看來，大量的數(shù)據(jù)目的并非是為了填充緩沖區(qū)，而是為了繞過tcpip.sys的某處判斷，從而進入漏洞出發(fā)的函數(shù)調用邏輯。

問題出現(xiàn)在smbv2后的一個特性Tree Connect，用來處理共享服務的特性，opcode：0x03，而整個問題，確是多個地方導致的。下面我們就一起來進入今天的旅程吧!

Github地址：https://github.com/lgandx/PoC/tree/master/SMBv3%20Tree%20Connect

漏洞復現(xiàn)

首先，網上關于這個漏洞的觸發(fā)方法有很多，比較通用的是twitter中某老外提到的Powershell的方法，最為簡單，首先我們調試的環(huán)境是：Windows 10 x64 build 1607

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

接下來我們在kali2.0里運行漏洞腳本。

kali2.0里運行漏洞腳本

隨后執(zhí)行"dir \ip\PATH"，漏洞觸發(fā)，通過windbg雙機聯(lián)調，此時捕捉到了BSOD。

BSOD

可以看到提示此時問題出現(xiàn)在mrxsmb20.sys中，問題函數(shù)是Smb2ValidateNegotiateInfo，來看一下觸發(fā)位置的代碼。

  1. kd> p 
  2. mrxsmb20!Smb2ValidateNegotiateInfo+0x17: 
  3. fffff803`1869c7d7 66394114        cmp     word ptr [rcx+14h],ax 
  4. kd> r rcx 
  5. rcx=0x00000000`00000000 

此時rcx的值為0x0，是一處無效地址，因此這是由于空指針引用導致的BSOD，接下來繼續(xù)執(zhí)行可以看到Windows 10引發(fā)藍屏。

Windows 10引發(fā)藍屏

回溯及數(shù)據(jù)包分析(important!)

我們來看一下mrxsmb20.sys關于Tree Connect特性的一些內容，代碼邏輯相對簡單。

mrxsmb20.sys關于Tree Connect特性

可以看到執(zhí)行到Smb2ValidateNegotiateInfo函數(shù)有兩條邏輯調用，一個是Smb2TreeConnect_CopyData，一個是Smb2TreeConnect_Receive，這里我就把我回溯的結果和大家分享一下，首先，通過Smb2TreeConnect_Receive來接收smb的Tree Connect數(shù)據(jù)，這個是通過opcode來決定的。

正常情況下不會進入Smb2TreeConnect_CopyData，但一旦由不正常(后面會提到)數(shù)據(jù)包執(zhí)行，則會在Receive之后進入CopyData函數(shù)的處理邏輯，從而引發(fā)漏洞。

這里數(shù)據(jù)包分析很關鍵，因為在漏洞觸發(fā)過程中，就是由于數(shù)據(jù)包的問題導致的。

來看一下Smb最關鍵的這個數(shù)據(jù)包。

Smb最關鍵的這個數(shù)據(jù)包

來看一下Smb頭部的協(xié)議格式。

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

在協(xié)議格式中Opcode指示smb類型

在協(xié)議格式中Opcode指示smb類型

注意數(shù)據(jù)包中對應位置，opcode值是0x03，就是tree connect的處理。同時這里在后面分析中我們要用到，注意Data數(shù)據(jù)之前的長度。其中包含了NetBIOS Session Service 4字節(jié)，和 SMB2 Header + Tree Connect Body 80字節(jié)，以及 Data n字節(jié)。這個非常重要，后續(xù)分析我們會用到。

漏洞分析

剛開始，我天真的以為是CopyData引發(fā)的某些異常，后來發(fā)現(xiàn)我錯了，其實這個漏洞可以看成利用tcpip.sys中的某些邏輯特性，以及mrxsmb20.sys中對于相關結構的檢查不夠嚴格導致的空指針引用BSOD，而整個漏洞形成，我是利用正常和不正常的對比才終于發(fā)現(xiàn)。在分析的過程中，大量不透明的結構體引用讓我有點尷尬，期待更熟悉SMB的大牛能夠繼續(xù)豐富分析。

正常的SMB2 Tree Connect包是不會觸發(fā)異常的。

SMB2 Tree Connect包

首先我們來看一下正常的邏輯調用，關鍵函數(shù)在tcpip.sys中的TcpDeliverDataToClient，這個函數(shù)負責處理接收到的數(shù)據(jù)包，在一個while(1)循環(huán)中。

  1. char __fastcall TcpDeliverDataToClient(PKSPIN_LOCK SpinLock, KSPIN_LOCK *a2, _QWORD *a3, _QWORD **a4) 
  2. { 
  3.  while ( 1 ) 
  4.   { 
  5.     …… 
  6.     v22 = (unsigned int)vars30; 
  7.     v23 = TcpIndicateData(v7, v6, v5, &v72); 
  8.     v24 = v71; 
  9.     if ( !(v6[3] + v6[4]) ) 
  10.       break; 
  11.     …… 

在這個循環(huán)中，剛進入循環(huán)位置有一個if語句，后面我們會提到，在接收到TreeConnect包之后，不會進入if語句，而是執(zhí)行下面的函數(shù)調用，在TcpIndicateData函數(shù)內部會調用到之前提到的Smb2TreeConnect_Receive，注意這一切現(xiàn)在都是在我們發(fā)送一個正常數(shù)據(jù)包時完成的。(接下來我們會分析到為什么是正常的)

在這個函數(shù)入口下條件斷點。

  1. kd> bp tcpip!TcpDeliverDataToClient ".if(poi(rbx+20)==0x1E4){;}.else{g;}" 
  2. kd> g 
  3. tcpip!TcpDeliverDataToClient: 
  4. fffff801`f18017a0 4055            push    rbp 
  5. kd> dd rbx+20 L1 
  6. ffffb304`06865c58  000001e4 

命中時，rbx會存放一個結構體，這個結構體按照IDA的反饋來看是一個KSPIN_LOCK自旋鎖，windows內核同步處理的一種機制，這個暫且不管，注意一下rbx結構體+20位置的值，是1e4，這個值轉換成10進制就是484，正好是我們發(fā)送的400個C的Data數(shù)據(jù)加剛才我們提到的頭部84字節(jié)的長度。

接下來進入TcpIndicateData函數(shù)后會命中Smb2TreeConnect_Receive函數(shù)開始進行接收處理。

  1. kd> p 
  2. tcpip!TcpDeliverDataToClient+0x209: 
  3. fffff801`f18019a9 e8e2810100      call    tcpip!TcpIndicateData (fffff801`f1819b90) 
  4. kd> dd rbx 
  5. ffffb304`06865c38  aa9ce398 fffff801 00000000 00000000 
  6. ffffb304`06865c48  00000000 00000000 00000000 00000000 
  7. ffffb304`06865c58  000001e4 00000000 00000000 00000000 
  8. ffffb304`06865c68  00000000 00000000 00000000 00000000 
  9. ffffb304`06865c78  06865c60 ffffb304 00000000 00000000 
  10. ffffb304`06865c88  00000000 00000000 00000000 00000000 
  11. ffffb304`06865c98  00000000 00000000 00000000 00000000 
  12. ffffb304`06865ca8  00000000 00000000 00000000 00000001 
  13. kd> p 
  14. Breakpoint 1 hit 
  15. mrxsmb20!Smb2TreeConnect_Receive: 
  16. fffff801`f3fbc4b0 48895c2420      mov     qword ptr [rsp+20h],rbx 

處理過程很長，這里我直接略過，在處理結束后會多層ret后返回到TcpDeliverDataToClient函數(shù)中，仍然處于while循環(huán)中。

  1. kd> bp tcpip!TcpIndicateData+0x268 
  2. kd> g 
  3. Breakpoint 3 hit 
  4. tcpip!TcpIndicateData+0x268: 
  5. fffff80a`72c39df8 c3              ret 
  6. kd> p 
  7. tcpip!TcpDeliverDataToClient+0x20e: 
  8. fffff80a`72c219ae 833defa51a0001  cmp     dword ptr [tcpip!MICROSOFT_TCPIP_PROVIDER_Context+0x24 (fffff80a`72dcbfa4)],1 
  9. kd> p 
  10. tcpip!TcpDeliverDataToClient+0x215: 
  11. fffff80a`72c219b5 448bf0          mov     r14d,eax 

這里我列舉一下返回過程的逐層調用邏輯，因為kb回溯不到。Smb2TreeConnect_Receive -> SmbReceiveInd -> VctIndRecv -> SmbWskReceiveEvent -> afd!WskProTLEventReceive -> tcpip!TcpIndicateData -> tcpip!TcpDeliverDataToClient。

接下來就是關鍵了，首先會執(zhí)行一處sub匯編指令。

  1. kd> p 
  2. tcpip!TcpDeliverDataToClient+0x2b9: 
  3. fffff80a`72c21a59 48297b20        sub     qword ptr [rbx+20h],rdi 
  4. kd> r rdi 
  5. rdi=00000000000001e4 
  6. kd> dd rbx+20 L1 
  7. ffffc10c`9fe79e78  000001e4 

這個相減之后，會將rbx結構體對應的長度變成0，隨后，會到達一處cmp操作，這處cmp操作會將這個值作為一個判斷條件。

  1. kd> p 
  2. tcpip!TcpDeliverDataToClient+0x2de: 
  3. fffff80a`72c21a7e 4c896b48        mov     qword ptr [rbx+48h],r13 
  4. kd> p 
  5. tcpip!TcpDeliverDataToClient+0x2e2: 
  6. fffff80a`72c21a82 488b4320        mov     rax,qword ptr [rbx+20h] 
  7. kd> dd rbx+18 L1 
  8. ffffc10c`9fe79e70  00000000 
  9. kd> dd rbx+20 L1 
  10. ffffc10c`9fe79e78  00000000 
  11. kd> p 
  12. tcpip!TcpDeliverDataToClient+0x2e6: 
  13. fffff80a`72c21a86 48034318        add     rax,qword ptr [rbx+18h] 
  14. kd> p 
  15. tcpip!TcpDeliverDataToClient+0x2ea: 
  16. fffff80a`72c21a8a 0f858dfeffff    jne     tcpip!TcpDeliverDataToClient+0x17d (fffff80a`72c2191d) 
  17. kd> p 
  18. tcpip!TcpDeliverDataToClient+0x2f0: 
  19. fffff80a`72c21a90 48837e2000      cmp     qword ptr [rsi+20h],0 

來看一下這一段偽代碼。

  1. while ( 1 ) 
  2.   { 
  3.       v70 = v10; 
  4.       v69 = TcpSatisfyReceiveRequests(v7); 
  5.     if ( v24 >= v23 ) 
  6.     { 
  7.     } 
  8.         else 
  9.     { 
  10.       v25 = (char *)ReceiveDpcTable + 24 * v21; 
  11.       v26 = v23 - v24; 
  12.       v27 = v7[2]; 
  13.       v70 = v26; 
  14.       *(_QWORD *)(*(_QWORD *)(v27 + 128) + (v21 << 7) + 56) -= v24; 
  15.       v28 = *((_DWORD *)v25 + 5); 
  16.       if ( v28 & 1 ) 
  17.         *((_DWORD *)v25 + 5) = v28 | 4; 
  18.       else 
  19.         TcpStartRcvWndTuningTimer(vars38); 
  20.       v6[4] -= v26; 
  21.       v29 = v6[9]; 
  22.       v6[3] = 0i64; 
  23.       if ( v26 + v29 ) 
  24.       { 
  25.         TcpAdvanceTcbRcvWnd(v7, (unsigned int)(v26 + *((_DWORD *)v6 + 18))); 
  26.         v6[9] = 0i64; 
  27.       } 
  28.       else 
  29.       { 
  30.         v6[9] = 0i64; 
  31.       } 
  32.     } 
  33.     if ( !(v6[3] + v6[4]) ) 
  34.       break; 

在偽代碼最后的位置，會對兩個值進行判斷，如果兩個值之和為0，則條件成立，程序會跳出循環(huán)，剛才的跟蹤我們可以發(fā)現(xiàn)，v6就是結構體，v6[4]的值來源于它自身減v26，而v26就是它自身，最后它的值為0，而剛才跟蹤v6[3]的值也為0(如果知道結構體就好清楚v6到底是什么了T.T)。

經過對比調試，發(fā)現(xiàn)在正常的處理SMB Tree Connect包和觸發(fā)BSOD的不正常情況下有一處關鍵的跳轉邏輯，這里是一處if語句判斷，成立則break跳出while循環(huán)，不成立，會繼續(xù)執(zhí)行。

 

那么不正常的情況呢?之前的處理和之前的分析一樣，我們加大Data的值到1200，但是在返回后。

  1. kd> p 
  2. tcpip!TcpDeliverDataToClient+0x2b9: 
  3. fffff80a`72c21a59 48297b20        sub     qword ptr [rbx+20h],rdi 
  4. kd> r rdi 
  5. rdi=0000000000000404 
  6. kd> dd rbx+20 
  7. ffffc10c`a0643e78  00000504 

顯而易見，在我們加大Data長度的時候，到相減位置結構體對應位置的值是504，也就是1284，正好是Data的長度1200字節(jié) + 剛才分析到的84字節(jié)，而此時rdi的值只有0x404，也就是944長度，這是一個Max值，如果Data長度超過0x404，這里會認為還有數(shù)據(jù)，因此相減后v6[4]的值不為0。

也就是說在SMB Tree Connect數(shù)據(jù)交互過程中，TcpDeliverDataToClient中關于這個地方的邏輯處理是，會根據(jù)數(shù)據(jù)包的長度，如果數(shù)據(jù)包長度小于0x404，則相減時v26的值是長度本身，然后會break。如果數(shù)據(jù)包長度大于0x404，則v26的值為max值，也就是0x404，相減不為0，則不會break。

  1. kd> p 
  2. tcpip!TcpDeliverDataToClient+0x2bd: 
  3. fffff80a`72c21a5d 4533ed          xor     r13d,r13d 
  4. kd> dd rbx+20 
  5. ffffc10c`a0643e78  00000100 

這造成了一個問題，就是剛才到的break位置由于v6[4]不為0，所以不執(zhí)行break，而是進入后續(xù)的處理。

  1. kd> p 
  2. tcpip!TcpDeliverDataToClient+0x2e2: 
  3. fffff80a`72c21a82 488b4320        mov     rax,qword ptr [rbx+20h] 
  4. kd> p 
  5. tcpip!TcpDeliverDataToClient+0x2e6: 
  6. fffff80a`72c21a86 48034318        add     rax,qword ptr [rbx+18h] 
  7. kd> p 
  8. tcpip!TcpDeliverDataToClient+0x2ea: 
  9. fffff80a`72c21a8a 0f858dfeffff    jne     tcpip!TcpDeliverDataToClient+0x17d (fffff80a`72c2191d) 
  10. kd> p 
  11. tcpip!TcpDeliverDataToClient+0x17d: 
  12. fffff80a`72c2191d 49833f00        cmp     qword ptr [r15],0 
  13. kd> p 
  14. tcpip!TcpDeliverDataToClient+0x181: 
  15. fffff80a`72c21921 0f85e9010000    jne     tcpip!TcpDeliverDataToClient+0x370 (fffff80a`72c21b10) 

接下來，程序會回到while入口位置，接下來會進入之前提到沒有進入的if語句處理，這是由于剛才沒有break結束循環(huán)的原因，此時會進入if語句的處理，函數(shù)中所調用的函數(shù)都是Complete，猜測都是和結束數(shù)據(jù)包相關處理有關。

  1. kd> p 
  2. tcpip!TcpDeliverDataToClient+0x1c1: 
  3. fffff80a`72c21961 e99bfeffff      jmp     tcpip!TcpDeliverDataToClient+0x61 (fffff80a`72c21801) 
  4. kd> p 
  5. tcpip!TcpDeliverDataToClient+0x61: 
  6. fffff80a`72c21801 48837b0800      cmp     qword ptr [rbx+8],0 
  7. kd> dd rbx+8 
  8. ffffc10c`a0643e60  9d8c2fa0 ffffc10c 9d8c2fa0 ffffc10c 

來看一下這個if語句。

  1. while ( 1 ) 
  2.  { 
  3.    if ( v6[1] ) 
  4.    { 
  5.      if ( !*v5 ) 
  6.        break; 
  7.      v9 = v6[1]; 
  8.      v10 = v6[2]; 
  9.      *((_BYTE *)v6 + 98) &= 0xFEu; 
  10.      v69 = v9; 
  11.      v6[1] = 0i64; 
  12.      v6[2] = 0i64; 
  13.      v11 = vars30; 
  14.      v71 = v10; 
  15.      LODWORD(v12) = TcpSatisfyReceiveRequests(v7, 0, (__int64)v6, vars30, v5, &v69, &v66); 
  16.     } 
  17.   } 

在這個if語句中，會調用TcpSatisfyReceiveRequests函數(shù)，這個函數(shù)中第六個參數(shù)，也就是v69是很關鍵的，這個值決定了后面的空指針引用，接下來進入這個函數(shù)。

  1. int __fastcall TcpSatisfyReceiveRequests(PKSPIN_LOCK SpinLock, char a2, __int64 a3, signed int a4, __int64 *a5, __int64 *a6, _DWORD *a7) 
  2. { 
  3.       v8 = *a5; 
  4.   v95 = SpinLock; 
  5.   v9 = *a6;                                     // RBP+148 
  6.       v38 = *(_QWORD *)(v9 + 48); 
  7.       v39 = *(_QWORD *)(v9 + 56); 
  8.       v40 = *(_QWORD *)(v9 + 8); 
  9.       v41 = *(_QWORD *)(v9 + 72); 
  10.       v93 += v38; 
  11.       v99 += *(_QWORD *)(v9 + 40); 
  12.       v42 = *(_QWORD *)v9; 
  13.       _guard_dispatch_icall_fptr(v40, 0i64, v38, v39);// call WskProTLReceiveComplete 

這個函數(shù)中的_guard_dispatch_icall_fptr調用了WskProTLreceiveComplete函數(shù)，而v40參數(shù)和v9結構體有關，v9是由傳入第六個參數(shù)，也就是剛才提到的v69有關，v69又來自于v6[1]，而這個結構體是和Complete有關，但是在TreeConnect數(shù)據(jù)包中卻沒有對這個結構體進行賦值。

隨后在WskProTLReceiveComplete中，會將rcx，也就是第一個參數(shù)v40，進行傳遞(64位Windows系統(tǒng)中，參數(shù)傳遞通過寄存器，第一個參數(shù)是rcx，第二個是rdx，第三個是r8，第四個是r9)。在后面的分析中，省略了無關的匯編過程，只留關鍵的給大家分享。

  1. kd> p 
  2. afd!WskProTLReceiveComplete+0x34: 
  3. fffff80a`7365aa84 488bd9          mov     rbx,rcx 
  4. ………… 
  5. kd> p 
  6. afd!WskProTLReceiveComplete+0x8e: 
  7. fffff80a`7365aade 488bcb          mov     rcx,rbx 
  8. kd> r rbx 
  9. rbx=ffffc10ca01ba010 
  10. kd> p 
  11. afd!WskProTLReceiveComplete+0x91: 
  12. fffff80a`7365aae1 ff15512d0200    call    qword ptr [afd!_imp_IofCompleteRequest (fffff80a`7367d838)] 

經過一系列傳遞后，這個第一個參數(shù)會直接傳給IofCompleteRequest函數(shù)，這個函數(shù)是irp完成函數(shù)，其實是一個中間過程，同步irp完成，后面就是善后工作。

在函數(shù)中，參數(shù)繼續(xù)傳遞。

  1. kd> p 
  2. nt!IopfCompleteRequest+0xb: 
  3. fffff800`9464b81b 4881ec00010000  sub     rsp,100h 
  4. kd> p 
  5. nt!IopfCompleteRequest+0x12: 
  6. fffff800`9464b822 488bd9          mov     rbx,rcx 
  7. ………… 
  8. kd> p 
  9. nt!IopfCompleteRequest+0x109: 
  10. fffff800`9464b919 488bd3          mov     rdx,rbx 
  11. kd> p 
  12. nt!IopfCompleteRequest+0x10c: 
  13. fffff800`9464b91c 488bce          mov     rcx,rsi 
  14. kd> p 
  15. nt!IopfCompleteRequest+0x10f: 
  16. fffff800`9464b91f ff5735          call    qword ptr [rdi+35h] 
  17. kd> t 
  18. Breakpoint 0 hit 
  19. mrxsmb!SmbWskReceiveComplete: 
  20. fffff80a`731d6950 48895c2408      mov     qword ptr [rsp+8],rbx 

在IofCompleteRequest函數(shù)中，會有一處調用回到SmWskReceivComplete函數(shù)，而結構體會交給rdx，也就是第二個參數(shù)進入這個函數(shù)。隨后這個參數(shù)會連續(xù)傳遞。先來看一下之前的堆?；厮?。

  1. kd> kb 
  2. RetAddr           : Args to Child                                                           : Call Site 
  3. fffff800`9464b922 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : mrxsmb!SmbWskReceiveComplete 
  4. fffff80a`7365aae7 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopfCompleteRequest+0x112 
  5. fffff80a`72c60d9d : fffff800`963d54a8 ffffc10c`9ed02780 fffff800`963d54b0 fffff800`963d547c : afd!WskProTLReceiveComplete+0x97 
  6. fffff80a`72c21860 : 00000000`00000002 ffffc10c`a0643d00 00000000`00000007 00000000`00000000 : tcpip!TcpSatisfyReceiveRequests+0x3cd 
  7. 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!TcpDeliverDataToClient+0xc0 

之后參數(shù)會連續(xù)進行傳遞，首先會把當前rdx+b8存放的值交給r14，之后把r14+40位置的值交給r8，最后引用的就是r8+98位置的值。

  1. kd> p 
  2. mrxsmb!SmbWskReceiveComplete+0x1d: 
  3. fffff80a`731d696d 488bda          mov     rbx,rdx 
  4. kd> p 
  5. mrxsmb!SmbWskReceiveComplete+0x20: 
  6. fffff80a`731d6970 4c8bb2b8000000  mov     r14,qword ptr [rdx+0B8h] 
  7. ………… 
  8. kd> p 
  9. mrxsmb!SmbWskReceiveComplete+0x7f: 
  10. fffff80a`731d69cf 4d8b4640        mov     r8,qword ptr [r14+40h]//1 
  11. kd> dd r14+40 
  12. ffffc10c`a01ba168  9fdf3c58 ffffc10c 

可以看到，這個過程并沒有對這個值進行檢查，由于結構體不透明，不能確定到底對應存放的是什么，但其實這個結構體的連續(xù)調用我們可以理解為KPCR -> KTHREAD -> _EPROCESS -> Token這種關系，在Windows內核有很多這樣的域以及相關的結構體，而相互又是嵌套的。

這個結構體的值為0x0的原因可能就是由于這個complete部分的數(shù)據(jù)包是由于SMB Tree Connect過長引起的，而mrxsmb20.sys中卻沒有對相關結構體進行檢查。

  1. kd> p 
  2. mrxsmb!VctIndDataReady+0x36: 
  3. fffff80a`731d6a56 498bf8          mov     rdi,r8 
  4. ………… 
  5. kd> p 
  6. mrxsmb!VctIndDataReady+0x146: 
  7. fffff80a`731d6b66 488bd7          mov     rdx,rdi 
  8. kd> p 
  9. mrxsmb!VctIndDataReady+0x149: 
  10. fffff80a`731d6b69 488bcb          mov     rcx,rbx 
  11. kd> p 
  12. mrxsmb!VctIndDataReady+0x14c: 
  13. fffff80a`731d6b6c ff15eeed0200    call    qword ptr [mrxsmb!_guard_dispatch_icall_fptr (fffff80a`73205960)] 
  14. kd> r rdx 
  15. rdx=ffffc10c9fdf3c58 
  16. kd> t 
  17. mrxsmb!guard_dispatch_icall_nop: 
  18. fffff80a`731d8a30 ffe0            jmp     rax 
  19. kd> p 
  20. mrxsmb20!Smb2TreeConnect_CopyData: 
  21. fffff80a`7546b6c0 48895c2410      mov     qword ptr [rsp+10h],rbx 

最后進入CopyData后，會引用這個結構體+98偏移位置的值，進入漏洞觸發(fā)的函數(shù)，而沒有對這個值進行檢查。

  1. kd> p 
  2. mrxsmb20!Smb2TreeConnect_CopyData+0x32: 
  3. fffff80a`7546b6f2 488b8b98000000  mov     rcx,qword ptr [rbx+98h] 
  4. kd> p 
  5. mrxsmb20!Smb2TreeConnect_CopyData+0x39: 
  6. fffff80a`7546b6f9 e8c210ffff      call    mrxsmb20!Smb2ValidateNegotiateInfo (fffff80a`7545c7c0) 
  7. kd> dd rbx+98 
  8. ffffc10c`9fdf3cf0  00000000 00000000 

最后在函數(shù)中引用空指針，引發(fā)了BSOD。

責任編輯：趙寧寧 來源： 安全客
漏洞SMBv3BSOD
相關推薦

2017-02-07 11:00:26

2011-03-03 11:26:09

2010-07-16 15:01:53

2009-10-29 13:24:41

2010-10-09 14:59:30

2009-10-21 14:31:15

漏洞補丁

2009-07-01 09:22:33

2009-10-22 11:28:38

2009-02-03 09:06:26

2009-10-24 10:29:56

2009-12-03 14:52:27

2011-12-29 09:21:09

TomcatHashtable

2009-10-27 14:17:49

2013-05-17 10:43:32

2009-10-29 12:27:54

2009-10-22 11:36:55

漏洞補丁

2009-10-25 12:40:29

2010-01-12 11:58:14

Cisco防火墻拒絕服務漏洞

2010-10-08 12:21:22

2010-09-14 16:54:16

點贊
收藏

51CTO技術棧公眾號