在某一個平行宇宙中,各位讀者大大現在看到的應該是一篇關于網絡協議的文章。
這個平行宇宙與當前宇宙的分叉點來源于2個小時前,我點了一下Wireshark抓包,一刹那,藍屏了,那篇文章中近一段時間寫的内容沒了。
我差點拍案而起,WTF!保存啊保存,一個不留神就忘記了。
事情是這樣的:
我想抓一些DHCP協議的數據包,于是将網卡禁用,然後開啟Wireshark,打算把一會兒啟用網卡後的通信過程抓下來。然而等我雙擊網卡開始抓包的一瞬間,藍了!
捶足頓胸之際,不小心瞅見了藍屏界面上藍屏的驅動程序名字:npcap.sys,看來是Wireshark用的抓包驅動有問題呀!
這家夥害我害得這麼慘,我不打算放過它,決定找出來到底這程序哪裡寫的有問題。
等了幾分鐘,電腦重啟後,在C:\Windows目錄下找到了系統崩潰後産生的核心存儲文件:MEMORY.dmp,這個文件是操作系統崩潰後,Windows将内核的數據、所有進程、線程的執行上下文進行了保存,相當于對“案發現場”進行了“拍照”,用于事後定位問題。
注意,這個得提前設置好才會存儲,默認情況下隻會存儲一個很簡單的mini dump文件,不利于問題分析。
祭出内核分析神器:WinDbg,來加載分析dump文件。
因為已經知道崩潰位置位于npcap.sys文件,所以先去簡單了解了一下這個東西。
Linux上咱們使用tcpdump抓取數據包時,底層使用的核心庫就是libpcap,這是一個開源項目,在Windows上對應的就是winpcap。後來在Win7之後,Windows上使用了更現代化的抓包接口,Wireshark默認使用npcap來代替了傳統的winpcap。
既然是開源項目,事情就好辦了,有源碼,有PDB符号文件。
源碼大家知道,PDB文件可能有些人不知道。我們知道C/C 這類語言編譯完成後,所有的函數名字、參數、數據結構定義等信息就丢失了,剩下的都是CPU指令了。那萬一程序出了問題程序員怎麼分析呢?這就需要pdb文件了,pdb是程序數據庫的意思,這裡面有前面說的那些信息。
在npcap項目的官網,找到了npcap.sys驅動程序對應版本的npcap.pdb文件,下載後,載入WinDbg中,可以看到程序崩潰的函數調用堆棧:
看到了吧,有了PDB文件,連源代碼路徑都顯示出來了。
在GitHub上找到了這個openclos.c文件,定位到最後導緻崩潰的函數:NPF_FreeCapData
具體是崩潰在哪一行呢?
回頭看看windbg可以告訴我們具體那一行指令的地址,在上下文的RIP寄存器中可以看到:
看一下這個位置的指令是個啥:
導緻藍屏的是這一條指令:
mov rbx, [rdx 18h]
這條指令的意思是把rdx 18指向位置的内容,讀取到rbx寄存器中。又看了一下崩潰代碼是内存訪問異常,那肯定就是rdx 18這個地址有問題了。
地址有問題,那現在rdx是個啥呢?
我去,居然是0,空指針NULL啊!那不崩潰就怪了!
結合彙編指令和數據結構定義,就能鎖定源碼中的具體位置了:在源碼中的三級指針訪問中,第二級指針的pNBLCopy字段為空!而代碼中又沒有判斷為空指針的情況,就崩潰了~
再次結合函數調用棧和GitHub中的源代碼,可以看到這是在清理釋放抓取到的所有數據包時出現的問題,看下面代碼,這是在一個循環中,挨個釋放每個數據包所占據的資源,所有數據包以雙鍊表形式串聯了起來。
問題分析到這裡,我已經按捺不住心裡的激動了,難道我發現了一個0day漏洞?要知道,驅動程序空指針bug用的好可是能做内核級攻擊的!一個漏洞都是值不少$的。
剛剛幻想了1秒鐘,馬上清醒過來,等等,我這版本好像不是最新的,我康康最新的版本還有沒有這個問題。
結果潑了我一盆冷水,新的版本,已經增加了對這個指針是否為空的判斷了:
哎!與财富擦肩而過~
作者:軒轅之風
來源:編程技術宇宙(ID:xuanyuancoding)
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!