久久久噜噜噜久久中文字幕色伊伊,av免费高清网址在线播放,黑逼白逼一样操,在线岛国片免费无码AV

摘要

索引是數(shù)據(jù)庫優(yōu)化性能的關鍵技術，同時也是從9i開始（前面未做考證）到現(xiàn)今的12C中，一直存在的安全隱患。索引給數(shù)據(jù)庫帶來的安全隱患有多種方式，例如：在PARAMETERS中注入惡意代碼導致的緩沖區(qū)溢出（CVE-2012-0052）；通過SYSTEM.OL$插入觸發(fā)器，任意執(zhí)行SQL語句（CVE-2011-3512）；拿到高權限用戶的表的創(chuàng)建索引權限，進行任意提權（CVE-2010-0902）等。經(jīng)過多年發(fā)展，大部分安全漏洞已經(jīng)被徹底封死，但CVE-2010-0902帶來的提權思路并未封死，直至今天在12C下，如果條件允許還能死灰復燃。

要想徹底根除索引權限帶來的（CVE-2010-0902）安全隱患，就必須搞清楚三個問題：1.索引可以舍棄嗎？ 2.如何利用索引提權？3. 如何合理配置索引？

Index 

大部分情況下，對于一個存在著安全隱患的功能來說，最穩(wěn)妥的處理方式就是棄之不用。但總有一些功能我們沒法直接舍棄，只能盡更大的努力去配置，而索引就屬于這樣的一種功能。

索引的價值在于能夠極大地提高特定數(shù)據(jù)的查詢速度。因為數(shù)據(jù)庫的最基層單位是塊，所有的數(shù)據(jù)在物理磁盤上是以塊的形式存儲的，為確保對磁盤操作的原子性，訪問數(shù)據(jù)就會一并訪問所有數(shù)據(jù)塊。磁盤上的這些數(shù)據(jù)塊與鏈表類似，它們都包含一個數(shù)據(jù)段和一個指針，指針指向下一個節(jié)點（數(shù)據(jù)塊）的內(nèi)存地址，而且它們都不需要連續(xù)存儲（即邏輯上相鄰的數(shù)據(jù)塊在物理上可以相隔很遠）。

當我們要查詢某一字段的時候，如果該值是唯一的，會使用線性查找，理論上要訪問N/2個數(shù)據(jù)塊，其中N指的是一個表所涵蓋的所有數(shù)據(jù)塊。如果該字段值不唯一，那么就更麻煩了，要搜索整個表空間，理論上要訪問全部N個數(shù)據(jù)塊。

然而，如果我們將這些唯一值的字段進行排序，就可以使用二分查找，也就是說理論上只要訪問log2 N個數(shù)據(jù)塊就可以找到目標。同樣，對不唯一值字段進行排序，找到邊緣值，也就不用再搜索表中的其他數(shù)據(jù)塊了。這樣一來，性能也會有實質性的提升。

而索引完成的正是對特定字段進行排序的工作。最終往往會以“樹”的形式存儲。索引唯一明顯缺點就是額外占用磁盤空間。鑒于其突出價值，索引功能還是要好好保留，做好正確配置，小心使用。

Index Privilege提權

在Oracle對索引修修補補多個版本之后，大部分漏洞早已堵上，現(xiàn)在剩余的是利用創(chuàng)建索引權限進行提權的這類安全隱患。Oracle規(guī)定，只有表的所有者擁有對該表創(chuàng)建權限的權利。其他用戶想在別的用戶表上創(chuàng)建索引可以通過兩個途徑：1.簡單粗暴的系統(tǒng)權限- Create Any Index，如果一個用戶具有系統(tǒng)權限Create Any Index，則該用戶可以對任意用戶的表創(chuàng)建索引，即便對那張表沒有訪問權限）；2.細膩特定的對象權限- Create Index，指定某個用戶對一張?zhí)囟ǖ谋碛袆?chuàng)建索引的權限。下面，我們將舉個例子為大家說明如果一個低權限用戶擁有SYS用戶某張表的權限會發(fā)生什么？

首先創(chuàng)建用戶hacker_user，只給予hacker_user最基本的權限。

SYS用戶創(chuàng)建一張表test_table，這張表將是hacker_user用來提權的關鍵，向表中插入一條數(shù)據(jù)，最后把表的查詢和創(chuàng)建索引的權限給予低權限用戶hacker_user。

切到hacker_user用戶，首先建立調(diào)用者權限函數(shù)GETDBA。GETDBA的核心語句是：EXECUTE IMMEDIATE 'GRANT DBA TO hacker_user'; 這句話是把hacker_user提權到DBA權限。接下來就需要DBA權限用戶調(diào)用這個函數(shù)了。由于用戶hacker_user有SYS表test_table的創(chuàng)建索引權限，于是利用這個權限構造SYS用戶調(diào)用GETDBA，創(chuàng)建函數(shù)形索引可以利用SYS權限調(diào)用GETDBA函數(shù)，具體如下圖：

注：12C最新版本索引創(chuàng)建會失敗，提示缺乏INHERIT PRIVILEGES。INHERIT PRIVILEGES默認沒有賦予SYS。在SYS用戶下執(zhí)行GRANT INHERIT PRIVILEGES ON USER SYS TO PUBLIC ;可正常建立。具體內(nèi)容請查閱《ORACLE 12C 安全隱患系列（一）又喜又悲的新功能-INHERIT PRIVILEGES》一文。

創(chuàng)建成功后，執(zhí)行查詢語句，目的是調(diào)用一次索引，使其執(zhí)行，完成整個提權過程。最后查詢DBA用戶發(fā)現(xiàn)hacker_user已經(jīng)被成功提權。

這種提權的方式不僅可以針對SYS用戶，可以針對任意具有特定權限的用戶，目標往往就是利用這些權限，進行越權或提權操作。12C下對創(chuàng)建的所有用戶默認都賦予INHERIT PRIVILEGES，不會出現(xiàn)類似SYS的情況。這里就不用其他權限用戶給大家做額外的演示了，過程都是類似的，針對不同權限的用戶修改GETDBA中的語句GRANT DBA TO hacker_user 即可。

Index Privilege檢查和配置

Oracle對索引提權采用的是治標不治本的方式，因此就需要我們的數(shù)據(jù)庫用戶特別注意，要避免錯誤的配置導致不法分子對數(shù)據(jù)庫實施利用索引的提權攻擊。想要檢查是否存在Index Privilege入侵的隱患，可以切到SYS用戶下進行語句查詢：

SELECT OWNER||'.'||TABLE_NAME||':'||GRANTEE FROM DBA_TAB_PRIVS WHERE PRIVILEGE = 'INDEX' AND GRANTEE!=OWNER ORDER BY 1;

此語句可以批量檢查索引權限的擁有者和創(chuàng)建者是否相同，如果不同，需要進一步調(diào)查來確定是否存在索引注入的可能性?；蛞愿邫嘞抻脩魹閱挝?，檢查是否存在高權限用戶索引被賦予其他用戶的情況存在。

通過上述查詢，從中很容易發(fā)現(xiàn)用戶HACKER_USER具有test_table的索引權限，需要對其進行清理。清理請使用語句：REVOKE INDEX ON sys.test_table FROM hacker_user;

請注意，很多應用可以在數(shù)據(jù)庫上創(chuàng)建一些表并修改一些權限。例如Oracle eBusiness suite的某些版本，在安裝應用的時候把SYS.DUAL的索引權限賦予了public，直接導致了任意用戶可以利用SYS.DUAL上的索引漏洞執(zhí)行任意SQL語句（CVE-2015-0393）。

結論

Index Privilege的安全問題從9i到12c還一直存在，好似一塊甩不掉的狗皮膏藥，屬于典型的便利和安全之間的矛盾。想從兩者之間獲得平衡，Oracle必須從用戶的角度考慮，最大化地提高性能和用戶體驗。而涉及安全問題，目前就需要以圍魏救趙的方式進行封堵，防止索引權限提權的出現(xiàn)。因為這種方法無法從根源上切掉隱患，這就需要Oracle用戶時刻注意不要把表的索引權限賦予比創(chuàng)建表權限低的用戶，要始終繃緊安全這根弦。