oracle 12c 安全隐患系列（二）-k8凯发天生赢家

摘要

索引是数据库优化性能的关键技术，同时也是从9i开始（前面未做考证）到现今的12c中，一直存在的安全隐患。索引给数据库带来的安全隐患有多种方式，例如：在parameters中注入恶意代码导致的缓冲区溢出（cve-2012-0052）；通过system.ol$插入触发器，任意执行sql语句（cve-2011-3512）；拿到高权限用户的表的创建索引权限，进行任意提权（cve-2010-0902）等。经过多年发展，大部分安全漏洞已经被彻底封死，但cve-2010-0902带来的提权思路并未封死，直至今天在12c下，如果条件允许还能死灰复燃。

要想彻底根除索引权限带来的（cve-2010-0902）安全隐患，就必须搞清楚三个问题：1.索引可以舍弃吗？ 2.如何利用索引提权？3. 如何合理配置索引？

index 

大部分情况下，对于一个存在着安全隐患的功能来说，最稳妥的处理方式就是弃之不用。但总有一些功能我们没法直接舍弃，只能尽更大的努力去配置，而索引就属于这样的一种功能。

索引的价值在于能够极大地提高特定数据的查询速度。因为数据库的最基层单位是块，所有的数据在物理磁盘上是以块的形式存储的，为确保对磁盘操作的原子性，访问数据就会一并访问所有数据块。磁盘上的这些数据块与链表类似，它们都包含一个数据段和一个指针，指针指向下一个节点（数据块）的内存地址，而且它们都不需要连续存储（即逻辑上相邻的数据块在物理上可以相隔很远）。

当我们要查询某一字段的时候，如果该值是唯一的，会使用线性查找，理论上要访问n/2个数据块，其中n指的是一个表所涵盖的所有数据块。如果该字段值不唯一，那么就更麻烦了，要搜索整个表空间，理论上要访问全部n个数据块。

然而，如果我们将这些唯一值的字段进行排序，就可以使用二分查找，也就是说理论上只要访问log2 n个数据块就可以找到目标。同样，对不唯一值字段进行排序，找到边缘值，也就不用再搜索表中的其他数据块了。这样一来，性能也会有实质性的提升。

而索引完成的正是对特定字段进行排序的工作。最终往往会以“树”的形式存储。索引唯一明显缺点就是额外占用磁盘空间。鉴于其突出价值，索引功能还是要好好保留，做好正确配置，小心使用。

index privilege提权

在oracle对索引修修补补多个版本之后，大部分漏洞早已堵上，现在剩余的是利用创建索引权限进行提权的这类安全隐患。oracle规定，只有表的所有者拥有对该表创建权限的权利。其他用户想在别的用户表上创建索引可以通过两个途径：1.简单粗暴的系统权限- create any index，如果一个用户具有系统权限create any index，则该用户可以对任意用户的表创建索引，即便对那张表没有访问权限）；2.细腻特定的对象权限- create index，指定某个用户对一张特定的表有创建索引的权限。下面，我们将举个例子为大家说明如果一个低权限用户拥有sys用户某张表的权限会发生什么？

首先创建用户hacker_user，只给予hacker_user最基本的权限。

sys用户创建一张表test_table，这张表将是hacker_user用来提权的关键，向表中插入一条数据，最后把表的查询和创建索引的权限给予低权限用户hacker_user。

切到hacker_user用户，首先建立调用者权限函数getdba。getdba的核心语句是：execute immediate 'grant dba to hacker_user'; 这句话是把hacker_user提权到dba权限。接下来就需要dba权限用户调用这个函数了。由于用户hacker_user有sys表test_table的创建索引权限，于是利用这个权限构造sys用户调用getdba，创建函数形索引可以利用sys权限调用getdba函数，具体如下图：

注：12c最新版本索引创建会失败，提示缺乏inherit privileges。inherit privileges默认没有赋予sys。在sys用户下执行grant inherit privileges on user sys to public ;可正常建立。具体内容请查阅《oracle 12c 安全隐患系列（一）又喜又悲的新功能-inherit privileges》一文。

创建成功后，执行查询语句，目的是调用一次索引，使其执行，完成整个提权过程。最后查询dba用户发现hacker_user已经被成功提权。

这种提权的方式不仅可以针对sys用户，可以针对任意具有特定权限的用户，目标往往就是利用这些权限，进行越权或提权操作。12c下对创建的所有用户默认都赋予inherit privileges，不会出现类似sys的情况。这里就不用其他权限用户给大家做额外的演示了，过程都是类似的，针对不同权限的用户修改getdba中的语句grant dba to hacker_user 即可。

index privilege检查和配置

oracle对索引提权采用的是治标不治本的方式，因此就需要我们的数据库用户特别注意，要避免错误的配置导致不法分子对数据库实施利用索引的提权攻击。想要检查是否存在index privilege入侵的隐患，可以切到sys用户下进行语句查询：

select owner||'.'||table_name||':'||grantee from dba_tab_privs where privilege = 'index' and grantee!=owner order by 1;

此语句可以批量检查索引权限的拥有者和创建者是否相同，如果不同，需要进一步调查来确定是否存在索引注入的可能性。或以高权限用户为单位，检查是否存在高权限用户索引被赋予其他用户的情况存在。

通过上述查询，从中很容易发现用户hacker_user具有test_table的索引权限，需要对其进行清理。清理请使用语句：revoke index on sys.test_table from hacker_user;

请注意，很多应用可以在数据库上创建一些表并修改一些权限。例如oracle ebusiness suite的某些版本，在安装应用的时候把sys.dual的索引权限赋予了public，直接导致了任意用户可以利用sys.dual上的索引漏洞执行任意sql语句（cve-2015-0393）。

结论

index privilege的安全问题从9i到12c还一直存在，好似一块甩不掉的狗皮膏药，属于典型的便利和安全之间的矛盾。想从两者之间获得平衡，oracle必须从用户的角度考虑，最大化地提高性能和用户体验。而涉及安全问题，目前就需要以围魏救赵的方式进行封堵，防止索引权限提权的出现。因为这种方法无法从根源上切掉隐患，这就需要oracle用户时刻注意不要把表的索引权限赋予比创建表权限低的用户，要始终绷紧安全这根弦。