從三月開始，安華金和安全實驗室會陸續推出系列文章，專門以Oracle數據庫為研究對象，展開安全隱患的分析研究，為大家帶來安全防范建議，幫助大家做好數據庫安全防護。本期推出ORACLE 12C 安全隱患系列（一），如果您或您的團隊正在使用Oracle12C，或打算使用Oracle12C，請一定按照本文思路對用戶的inherit privileges權限進行合理分配，杜絕安全隱患。
在12.1之后的Oracle版本中引入了一個和安全相關的權限—INHERIT PRIVILEGES。這個權限可以賦予用戶或角色。喜的是，Oracle引入這個權限的目標是解決調用者權限可能造成的安全隱患。然而悲的是，在12.1的默認配置下，INHERIT PRIVILEGES并不會起到提高安全性的作用。只有用戶重新配置INHERIT PRIVILEGES才能真正達到Oracle設計INHERIT PRIVILEGES提高安全性目的。
要弄清楚如何正確配置INHERIT PRIVILEGES，首先要搞清楚三個問題：1.調用者方式的安全隱患。2. INHERIT PRIVILEGES是如何工作的？3. INHERIT PRIVILEGES應該如何配置？
Oracle函數、存儲過程的創建不同于其他數據庫，可以采取兩種截然不同的方式建立。一種是定義者權限（Definer’s right）,一種是調用者權限（Invoker’s right）。調用者權限創建的函數或存儲過程，在創建過程中不會判斷創建者是否擁有對存儲過程或函數中調用的表、視圖和對象的執行權限。簡單地說，就是調用者方式允許低權限用戶在函數或存儲過程中使用超越自身的權限。允許超越自身權限帶來了便利，也同時給數據庫帶來非法提權、非法操作、非法獲取敏感信息等一系列安全隱患。
為了講清楚隱患，這里舉一個例子：有一個低權限用戶hacker_user，他只有創建存儲過程和會話權限。
hacker_user使用調用者權限創建了函數 add_number。并把add_number的執行權限賦予全體，讓所有用戶都可以通過hacker_user. add_number的方式調用該函數。
至此無論是有DBA權限的dba_user還是只有會話權限的normal_user都可以使用hacker_user. add_number完成運算任務。
當hacker_user. add_number得到其他用戶充分信任后，hacker_user動了提升自己權限的心思。于是hacker_user首先使用調用者方式創建一個用于提權的存儲過程（change_me_dba）。由于使用的是調用者方式，即使“GRANT DBA TO hacker_user這種高危語句被嵌入其中，存儲過程也能順利創建。
接著hacker_user再偷偷對add_number進行修改，在add_number中調用change_me_dba.
hacker_user整個布局完成后，就靜靜等著其他用戶像以往一樣調用hacker_user. add_number。這種攻擊的方式不僅難以防護，還難以被察覺。低權限用戶使用hacker_user. add_number，依然會正常運算，同時也不會出現任何報錯信息。例如用normal_user調用hacker_user. add_number 正確運算，且無報錯，如果不去檢查hacker_user. add_number的源碼會很難發現，實際上hacker_user在私下已經偷偷對hacker_user. add_number動了手腳。
由于無異常、不報錯，被hacker_user修改后的add_number能安全地潛伏在數據庫中。等到類似dba_user這樣的DBA用戶調用hacker_user. add_number后，它會神不知鬼不覺地進行提權。
同樣地，即便是有DBA權限的dba_user調用也不會有任何異常。除非查詢dba_role_privs，才會抓到hacker_user的“狐貍尾巴”。
但分析如何提權，必須對所有hacker_user中的內容進行分析，因為發現問題的時候hacker_user很可能早就把add_number改了回去，把change_me_dba做了刪除，做到毀尸滅跡，以防止安全人員找到提權手法后，進行針對性封堵。
Oracle12.1為了解決上述問題，引入了inherit privileges和inherit any privileges 這兩組權限，用以限制用戶訪問其他用戶，使用調用者權限創建的函數或存儲過程。在12.1上正確配置權限后用dba_user調用add_number，不僅不會執行，且會出現ORA-06598錯誤，用以防止低權限用戶借用高權限進行非法操作。
inherit privileges通過GRANT和REVOKE進行賦權或取消賦權。invoking_user（dba_user）只把自己的inherit privileges賦予自己信任的procedure_owner（hacker_user）中，防止調用不安全的存儲過程或函數。
GRANT INHERIT PRIVILEGES ON USER invoking_user TO procedure_owner;
REVOKE INHERIT PRIVILEGES ON USER invoking_user FROM procedure_owner;
引入inherit privileges原本可以很好地解決低權限用戶利用調用者方式，騙取高權限的問題。但Oracle12.1默認對inherit privileges權限的賦予存在一定的問題。12.1在創建新用戶或升級到12.1后對老用戶都自動做了GRANT INHERIT PRIVILEGES ON USER USERNAME TO PUBLIC 的操作，使得inherit privileges的限制直接作廢。默認狀態下hacker_user依然可以用上述手段完成提權操作。
好的解決方法也需要合理的配置。如果配置不當，安全將成為一句空話。inherit privileges權限的辦法是好的，但不科學的默認配置毀了這一切。
默認任何用戶都把inherit privileges賦予PUBLIC的行為，很大程度是從兼容性的角度考慮的。雖然達到了兼容的目的，但卻破壞了安全的效果，而且很可能給后來者留下錯誤使用inherit privileges的范例。總結下來，inherit privileges合理配置應該遵循兩點：1.用戶只給可信且必要的存儲過程和函數的用戶賦予inherit privileges；2.DBA用戶不要給任何用戶inherit privileges 權限，防止出現低權限用戶被破解后利用調用者權限竊取DBA權限，實施非法行為。
針對上述兩個要點，我們首先檢查當前數據庫DBA用戶有SYSTEM、SYS和DBA_USER.
下一步再檢查這些DBA用戶是否已經給其他用戶inherit privileges，如果存在請進行回收，否則可能造成安全隱患。
dba_user用戶inherit privileges權限賦予public，回收該權限。否則，還可能出現DBA用戶誤使用有風險的函數或存儲過程的現象。
對每一個DBA使用類似檢查，修改DBA默認的賦權對象，再按照實際需求把用戶的inherit privileges權限賦予必要用戶。如此，既不影響用戶使用，又在一定程度上避免安全隱患。
當然如果您不愿意手動進行上述檢查和部署，可以通過安華金和的漏掃產品DBScan，進行針對性的專項檢查，并根據您的配置方案進行權限的自動部署。
Inherit privileges的出現說明Oracle對于安全問題已經越來越重視。但百密終有一疏，在默認情況下，新功能Inherit privileges形同虛設，并不能起到加強數據庫安全的效果。如果您或您的團隊正在使用Oracle12C，或打算使用Oracle12C，請一定按照本文思路對用戶的inherit privileges權限進行合理分配，杜絕安全隱患。
產品咨詢：4000 258 365 
