ORA-00600:[16703],[1403],[20]
2018-11-15 17:24阅读：
SQL> Conn /As Sysdba
Connected.
SQL> Select Object_name
From Dba_objects Where Object_name Like 'DBMS_SUPPORT%';
No Rows Selected
https://www.cnblogs.com/xifenfei/articles/8900317.html
继续上篇的tab$被清空(
ORA-600
16703故障解析—tab$表被清空),导致数据库启动异常的case
ORA-600 16703报错
数据库日志分析
数据库open成功同时报ORA-7445 kokeicbegin和ORA-600 kz
rini:!uprofile错误
再次启动数据库直接报ORA-600 16703错误
这里有一个其他现象,就是数据库在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
2017
with
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 = 1334610369
Found db_name = orcl
DUL> unload table TAB$( OBJ# number, DATAOBJ#
number,
2
TS# number, FILE# number, BLOCK#
number,
3
BOBJ# number, TAB# number, COLS number,
CLUCOLS number,
4
PCTFREE$ ignore, PCTUSED$ ignore, INITRANS ignore, MAXTRANS
ignore,
5
FLAGS ignore, AUDIT$ ignore, ROWCNT ignore, BLKCNT
ignore,
6
EMPCNT ignore, AVGSPC ignore, CHNCNT ignore, AVGRLN
ignore,
7
AVGSPC_FLB ignore, FLBCNT ignore,
8
ANALYZETIME ignore, SAMPLESIZE ignore,
9
DEGREE ignore, INSTANCES ignore,
10 INTCOLS
ignore, KERNELCOLS number, PROPERTY number)
11 cluster
C_OBJ#(OBJ#)
12 storage (
tablespace 0 segobjno 2 tabno 1 file
1 block 144);
.
unloading table
TAB$
0 rows
unloaded
DUL> unload table OBJ$( OBJ# number, DATAOBJ#
number, OWNER# number,
2
NAME clean varchar2(30), NAMESPACE ignore, SUBNAME clean
varchar2(30),
3
TYPE# number, CTIME ignore, MTIME ignore,
STIME ignore,
4
STATUS ignore, REMOTEOWNER ignore, LINKNAME
ignore,
5
FLAGS ignore, OID$ hexraw)
6
storage ( tablespace 0 segobjno 18 file 1 block 240);
.
unloading table
OBJ$
89804 rows unloaded
DUL>
|
这里可以明确表示tab$无记录,obj$有记录,从而启动的过程出现ORA-600
16703错误可以很好解释.由于数据库启动成功和报错几乎同时进行，以及上面看到的tab$记录不存在的情况，初步怀疑是有startup触发器清空tab$表记录
工具分析触发器表trigger$
这里果然看到一个after startup on
database的触发器,名字为DBMS_SUPPORT_DBMONITOR,而它调用的是DBMS_SUPPORT_DBMONITORP存储.
工具分析pl/sql表source$
对wraped加密的程序进行解密
这里可以明确的看到DBMS_SUPPORT_DBMONITORP存储过程备份tab$表到orachk中然后delete
tab$表,现在已经明确是由于DBMS_SUPPORT_DBMONITOR触发器在数据库重启之后开始执行调用DBMS_SUPPORT_DBMONITORP程序,如果判断数据库创建时间大于等于300天,便干掉tab$表,实现数据库破坏.
查找DBMS_SUPPORT_DBMONITOR等程序源头
分析相关程序创建时间,通过obj$表的ctime和name来判断
这里可以看出来DBMS_SUPPORT_DBMONITOR和DBMS_SUPPORT_DBMONITORP的创建时间基本上和数据库核心对象的创建时间相差无几,我们可以大概排除掉,是由于pl
sql等工具连接数据库导致该发问题(类似:
plsql
dev引起的数据库被黑勒索比特币实现原理分析和解决方案),很可能是在dbca创建库的过程中就已经带有了DBMS_SUPPORT_DBMONITOR等程序,如果这样那很可能是由于数据库的安装介质被破坏导致该问题.
分析DBMS_SUPPORT_DBMONITOR来源
这里已经很清晰,由于prvtsupp.plb被人注入了恶意脚本从而使得数据库被创建了DBMS_SUPPORT_DBMONITOR的触发器和DBMS_SUPPORT_DBMONITORP的存储过程,从而实现了对数据库的而易破坏.
确定破坏文件prvtsupp.plb来源于介质
这里比较明显,文件就是来源database\stage\Components\oracle.rdbms.dbscripts\11.2.0.4.0\1\DataFiles\filegroup2.jar\rdbms\admin\prvtsupp.plb文件被修改导致
通过md5码对比,可以确定是有人对软件的安装介质进行了破坏,从而实现了恶意代码的注入,从而实现了数据库300天之后重启之后无法正常启动而是出现类似ORA-00600:
internal error code, arguments: [16703], [1403], [20], [], [], [],
[], [], [], [], [], []的错误.
