加载中…ORA-00600:[16703],[1403],[20]
(2018-11-15 17:24:23) | 分类： oracle |
继续上篇的tab$被清空(ORA-600
16703故障解析—tab$表被清空),导致数据库启动异常的case
ORA-600 16703报错
http://www.xifenfei.com/wp-content/uploads/2017/07/ora-600-16703.png
数据库日志分析
数据库open成功同时报ORA-7445 kokeicbegin和ORA-600 kzrini:!uprofile错误
http://www.xifenfei.com/wp-content/uploads/2017/07/ora-600-kzrini-uprofile.jpg
再次启动数据库直接报ORA-600 16703错误
http://www.xifenfei.com/wp-content/uploads/2017/07/ora-600-16703.jpg
这里有一个其他现象,就是数据库在open成功的同时(同一秒内),开始报异常.重启之后直接报
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [16703], [1403], [20],
[], [], [], [], [], [], [], [], []
根据10046分析结果
以及以往恢复经验和mos,基本上可以确定是由于tab$和obj$记录不匹配导致该问题.而且是obj#=20的记录在tab$和obj$中不匹配.
分析tab$和obj$记录
Data UnLoader: 11.2.0.1.5 - Internal Only - on Wed Jul 05
01:28:53 2017with 64-bit io functions and the decompression
option Copyright (c) 1994 2017 Bernard van Duijnen All rights
reserved. Strictly Oracle Internal Use Only Found db_id = 1334610369Found db_name = orclDUL> unload table TAB$( OBJ# number, DATAOBJ# number, 2 # number, FILE# number, BLOCK# number, 3 # number, TAB# number, COLS number, CLUCOLS
number, 4 5 6 7 8 9 10 11 #(OBJ#) 12 file 1
block 144);.
unloading
table DUL> unload table OBJ$( OBJ# number, DATAOBJ# number, OWNER# number, 2 3 # number, CTIME ignore, MTIME ignore, STIME
ignore, 4 5 6 file 1
block 240);.
unloading
table DUL> |
这里可以明确表示tab$无记录,obj$有记录,从而启动的过程出现ORA-600
16703错误可以很好解释.由于数据库启动成功和报错几乎同时进行，以及上面看到的tab$记录不存在的情况，初步怀疑是有startup触发器清空tab$表记录
工具分析触发器表trigger$
http://www.xifenfei.com/wp-content/uploads/2017/07/startup-trigger.jpg
这里果然看到一个after startup on
database的触发器,名字为DBMS_SUPPORT_DBMONITOR,而它调用的是DBMS_SUPPORT_DBMONITORP存储.
工具分析pl/sql表source$
http://www.xifenfei.com/wp-content/uploads/2017/07/DBMS_SUPPORT_DBMONITOR.jpg
对wraped加密的程序进行解密
http://www.xifenfei.com/wp-content/uploads/2017/07/DBMS_SUPPORT_DBMONITOR-unwraped.jpg
这里可以明确的看到DBMS_SUPPORT_DBMONITORP存储过程备份tab$表到orachk中然后delete
tab$表,现在已经明确是由于DBMS_SUPPORT_DBMONITOR触发器在数据库重启之后开始执行调用DBMS_SUPPORT_DBMONITORP程序,如果判断数据库创建时间大于等于300天,便干掉tab$表,实现数据库破坏.
查找DBMS_SUPPORT_DBMONITOR等程序源头
分析相关程序创建时间,通过obj$表的ctime和name来判断
http://www.xifenfei.com/wp-content/uploads/2017/07/DBMS_SUPPORT_DBMONITOR-ctime.jpg
http://www.xifenfei.com/wp-content/uploads/2017/07/bootstrap-ctime.jpg
这里可以看出来DBMS_SUPPORT_DBMONITOR和DBMS_SUPPORT_DBMONITORP的创建时间基本上和数据库核心对象的创建时间相差无几,我们可以大概排除掉,是由于pl
sql等工具连接数据库导致该发问题(类似:plsql
dev引起的数据库被黑勒索比特币实现原理分析和解决方案),很可能是在dbca创建库的过程中就已经带有了DBMS_SUPPORT_DBMONITOR等程序,如果这样那很可能是由于数据库的安装介质被破坏导致该问题.
分析DBMS_SUPPORT_DBMONITOR来源
http://www.xifenfei.com/wp-content/uploads/2017/07/prvtsupp.jpg
http://www.xifenfei.com/wp-content/uploads/2017/07/20170711001626.jpg
这里已经很清晰,由于prvtsupp.plb被人注入了恶意脚本从而使得数据库被创建了DBMS_SUPPORT_DBMONITOR的触发器和DBMS_SUPPORT_DBMONITORP的存储过程,从而实现了对数据库的而易破坏.
确定破坏文件prvtsupp.plb来源于介质
http://www.xifenfei.com/wp-content/uploads/2017/07/jar.png
这里比较明显,文件就是来源database\stage\Components\oracle.rdbms.dbscripts\11.2.0.4.0\1\DataFiles\filegroup2.jar\rdbms\admin\prvtsupp.plb文件被修改导致
http://www.xifenfei.com/wp-content/uploads/2017/07/md5.jpg
通过md5码对比,可以确定是有人对软件的安装介质进行了破坏,从而实现了恶意代码的注入,从而实现了数据库300天之后重启之后无法正常启动而是出现类似ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [], [], [], [], [], [], []的错误.
喜欢
0
赠金笔