常見的核心漏洞的成因

不正確的zw函式呼叫

不要接受任何使用者輸入的核心物件傳遞給核心函式。

給驅動程式提供功能介面需要小心

if
(mmisaddressvalid
(p1)
)

那麼攻擊者只需要傳入乙個位元組在有效頁，比如0x8000這一頁是有效的的，0x9000這一頁是未分配的，傳入0x8fff將會使得系統崩潰。

其次mmisaddressvalid並不能準確地判斷pageout的頁面。**於微軟的說明：

典型的錯誤：

try
__except
(execute_handler_exception)if(
memcmp
(buff , buff2 , len).....

probeforread 只檢查在 probe 的那一刻， buff 位址是在使用者態位址範圍內。

在try,except塊之外進行讀寫，這個時候並不能保證buff還是使用者態的位址。

當一塊快取長度為0的時候，很多函式都不會對其進行檢驗而直接跳過，比如曾經的probefor***x:

所以當使用了probefor***驗證了引數，一樣要當心長度為0的時候的情況：

__try
__except
(execute_handler_exception)

當lenth = 0的時候，這樣的**一樣會導致系統崩潰。而且還有一點需要特別注意：

長度為空的快取如果用做一些函式的引數可能具有特別的意義，比如：對於 objectattributes->objectname的 length，如果為空，系統會以對應的引數開啟objectattributes->rootdirectory 的控制代碼，攻擊者可以先以低許可權得到乙個受保護物件的控制代碼，再以長度為空的快取，將控制代碼填入rootdirectory 來獲取高許可權的控制代碼。

千萬不要判斷使用者態的指標是否為null來判別是否放行，因為windows7及其之前是允許使用者申請位址為0的記憶體的，所以導致了可繞過這型別的判斷，

由此拓展的還有就是快取對齊的繞過方式和不正確的核心函式的呼叫。

probeforread 的第三個引數 alig 即對齊，如果沒有正確地傳遞這個函式，也會導致問題，例如對於 objectattributes ，系統預設按 1 來對齊，如果在對其引數處理中使用 sizeof(ulong)來對齊，就會對本來可以使用的引數引發異常，繞過保護或檢查。

obreferenceobjectbyhandle

obreferenceobjectbyhandle
(filehandle , access ,
null
(objecttype),.
..&fileobject);if
(wcsnicmp
(fileobject-
>filename...
.)

攻擊者可以傳入非檔案型別的控制代碼從而造成系統漏洞。

不能將任何使用者態位址傳入zw函式來傳遞給核心，使用者態記憶體未經過校驗傳遞給 zw*** 會讓系統忽略記憶體檢查（因為 zw*** 呼叫時認為上個模式已經是核心模式），即使你進行了校驗，傳遞這樣的記憶體給系統也可以引發崩潰（例如記憶體頁在呼叫時突然無效），即使你在外部有異常捕獲，也可能造成核心記憶體洩露、物件洩露，甚至許可權提公升等嚴重問題。

常見的錯誤：

__try

if
(iocontrolcode==ioctl_release_mutex)

例如可以對登錄檔、檔案、核心記憶體、程序執行緒等操作的功能性介面，一定要非常小心，如果不能完全杜絕存在被惡意利用的可能，一定要限制裝置控制的呼叫者，禁止一切非受信程序的呼叫。

如果不小心控制的話很可能會造成白利用這種攻擊。

更新時間於9.20號下午5點。

如有更深一步的理解再更新。

常見的核心漏洞的成因

常見的Web漏洞

常見的系統漏洞

常見的OAuth令牌漏洞

常見的核心漏洞的成因

常見的Web漏洞

常見的系統漏洞

常見的OAuth令牌漏洞

相關推薦