安全警报:Oracle 2018一月号安全补丁修复由来已久安全漏洞

简介:

在美西时间2018一月16日,北京时间今天凌晨,Oracle公司发布了 2018 年第一个安全补丁,这被称为 - Oracle Critical Patch Update,缩写为 CPU。

Oracle强烈推荐用户根据实际情况,尽快应用这些安全补丁。

8d8885405cbadac61c4aa66c7374cd43151c4436

我们看一下关于数据库的部分,Oracle这一次修复了什么漏洞。关于数据库部分有 5 个安全漏洞被修复,其中两个和数据库核心组件相关:Core RDBMS,值得引起注意,其他 3 个和组件相关:

1b47b8de0deeeea2737f333a10a8545330118af4

其中第一个和第五个的CVE编号分别是:CVE-2017-10282 ,意味着这是一个在2017年被披露的问题。这个问题在CVE网站未被披露。

第五个是 CVE-2018-2575 ,在CVE网站上可以找到简单的描述,但是核心信息是不会披露的,你不会了解到任何相关的内容,这是为了确保安全,但是这也为用户判断是否修复、是否可以通过其他方式绕过漏洞带来了困惑

1fe797ddcbb42f67bec79b5955b458b5da81d300

是否应用这些补丁?要想做出判断就必须深入了解诱发问题的可能情况。

我们看看第一个核心问题:CVE-2017-10282。这个问题会因为 Create Session, Execute Catalog Role 触发,也就是说这是因为权限引起的,影响的版本包括已经发布的12从版本:12.1.0.2, 12.2.0.1 。

我们来重现一下这个问题,首先在多租户数据库中,创建一个具有 execute_catalog_role 权限的用户 :

aab4d04a343aa7bb1784cba22eb6f05c75fb8f04

我们看看会发生什么样的风险。

具备了权限,当我执行了一条语句命令之后:

b55d2beb9956413f40d55550d80a19df71e2347e

执行SQL注入查询之后,这个普通用户获得了DBA的权限。这就是这个漏洞的影响之处。这是一个 12.2 版本的数据库。获得DBA权限的用户,就可以在数据库中为所欲为,这个漏洞够严重吗?

2e7c6a015e66a94efe9293fd1c28ae782768a262

如果了解了风险,就可以通过权限控制,防范这个风险,也就不一定非要通过补丁去修正。

清醒的认知风险,正是正确判断决策的开始。


原文发布时间为:2018-01-16

本文作者:盖国强

本文来自云栖社区合作伙伴“数据和云”,了解相关信息可以关注“数据和云”微信公众号

相关文章
|
Oracle 关系型数据库 数据库
实战篇:Oracle 数据坏块的 N 种修复方式
实战篇:Oracle 数据坏块的 N 种修复方式
实战篇:Oracle 数据坏块的 N 种修复方式
|
Oracle 关系型数据库 Linux
如果oracle用户下的$ORACLE_HOME bin oracle文件的属主或权限出了问题,那么该如何修复呢?
如果oracle用户下的$ORACLE_HOME bin oracle文件的属主或权限出了问题,那么该如何修复呢?
393 1
|
供应链 安全 Oracle
Oracle 4月安全通告
Oracle 4月安全通告
|
Oracle 安全 关系型数据库
Oracle学习(十四):管理用户安全
本文主要讲Oracle管理用户安全
117 0
Oracle学习(十四):管理用户安全
|
弹性计算 Oracle 网络协议
阿里云服务器Oracle开放1521端口教程(安全组配置)
在阿里云服务器上安装Oracle数据库,需要开放1521端口,在安全组设置即可开放云服务器1521端口
1457 0
阿里云服务器Oracle开放1521端口教程(安全组配置)
|
运维 Oracle 关系型数据库
实战篇:Oracle DataGuard 出现 GAP 修复完整步骤
实战篇:Oracle DataGuard 出现 GAP 修复完整步骤
实战篇:Oracle DataGuard 出现 GAP 修复完整步骤