2011-10-25 50 views
4

我與之合作的團隊最近面臨着使我們的軟件與第三方虛擬化軟件兼容的挑戰。此軟件使用內核驅動程序執行Windows本機註冊表API(ZwCreateKey等)的掛鉤。它通過在Ntdll中掛接呼叫來工作。我們的軟件也是相當低的水平,在某些情況下需要訪問真正的註冊表而不被掛鉤。爲什麼在內核模式下調用ZwCreateKey似乎規避了Windows安全?

我們正在探索使用我們自己的內核驅動程序調用ZwCreateKey等的可能性,代表我們避免他們的掛鉤。這基本上意味着創建一個NT Legacy驅動程序和一個提供我們自己的本地註冊表功能的用戶模式庫。庫和驅動程序非常簡單,我們只需使用IOCTL將ZwCreateKey等的所有參數傳遞給我們的驅動程序,然後調用內核版本的調用並返回結果。

該方法運行良好,並且我們似乎現在有虛擬化時讀取/寫入真實註冊表的系統。唯一的問題是我們的新系統似乎在Windows註冊表對象上安全運行。

ZwCreateKey需要訪問掩碼像這樣:

NTSTATUS ZwCreateKey(
    __out  PHANDLE KeyHandle, 
    __in  ACCESS_MASK DesiredAccess, 
    __in  POBJECT_ATTRIBUTES ObjectAttributes, 
    __reserved ULONG TitleIndex, 
    __in_opt PUNICODE_STRING Class, 
    __in  ULONG CreateOptions, 
    __out_opt PULONG Disposition 
); 

我的理解是,雖然我們現在在內核模式下運行,我們仍然有用戶的令牌的情況下。這應該意味着內核版本ZwCreateKey將失敗,就像用戶訪問屏蔽測試失敗時那樣。實際情況是,即使使用有限的令牌,當我們的驅動程序被調用時,它也能夠在受限用戶調用時在限制部件HKLM中創建密鑰。是什麼賦予了?我們應該自己執行ACL檢查嗎?我們需要做些什麼來限制我們在內核模式下的權限?任何幫助非常感謝。

回答

7

檢查this的解釋。基本上用戶模式下的Nt/Zw(ntdll)是同樣的事情 - 它們在實際執行操作之前首先執行廣泛的檢查。在從內核模式調用Zw函數時(與設備驅動程序的情況一樣),那些檢查被省略,因爲假定來自內核模式組件(例如驅動程序)的信息默認爲信任的

+1

Ahah ,是的,看起來像PreviousMode可能是問題... – Benj

+0

Windows內部花花公子Alex Ionescu在此覆蓋之前的模式:http://www.alex-ionescu.com/BH08-AlexIonescu.pdf,他建議所有系統調用(它基本上就是我正在做的)應該設置之前的模式,而不是設置之前的模式咒語「危險」。非常戲劇性,優秀的建議:-) – Benj

相關問題