Database Reference
In-Depth Information
Reading symbols from /u01/app/oracle/product/12.1.0/dbhome_1/lib/libodm12.so...(no debugging symbols
found)...done.
Loaded symbols for /u01/app/oracle/product/12.1.0/dbhome_1/lib/libodm12.so
Reading symbols from /u01/app/oracle/product/12.1.0/dbhome_1/lib
.....
(gdb) dump memory /root/output/oradump 0x00400000 0x0efaa000
(gdb)
Then we can read the dump file through strings command, as follows:
[root@ol6 output]# strings oradump | grep 'password' | less
Or more directly we can cat the memory used by process ID 12985:
cat /proc/12985/maps | less
00400000-0efaa000 r-xp 00000000 08:11 925027 /u01/app/oracle/
product/12.1.0/dbhome_1/bin/oracle
0f1aa000-0f409000 rw-p 0ebaa000 08:11 925027 /u01/app/oracle/
product/12.1.0/dbhome_1/bin/oracle
0f409000-0f438000 rw-p 00000000 00:00 0
10a29000-10a4a000 rw-p 00000000 00:00 0 [heap]
60000000-60001000 r--s 00000000 00:10 419873 /dev/shm/ora_orcl_9306126_0
60001000-60400000 rw-s 00001000 00:10 419873 /dev/shm/ora_orcl_9306126_0
60400000-60800000 rw-s 00000000 00:10 419874 /dev/shm/ora_orcl_9306126_1
60800000-60c00000 rw-s 00000000 00:10 419875 /dev/shm/ora_orcl_9306126_2
60c00000-61000000 rw-s 00000000 00:10 419879 /dev/shm/ora_orcl_9338895_0
61000000-61400000 rw-s 00000000 00:10 419880 /dev/shm/ora_orcl_9338895_1
61400000-61800000 rw-s 00000000 00:10 419881 /dev/shm/ora_orcl_9338895_2
Additionally, we can search shared memory as follows. This
cat
command can reveal values held in memory
such as the
sysawr
password below:
strings /dev/shm/* | grep 'password' | less
....
m user$ where user#=:1
by sysawr
password expire account lock
)change_password_on_first_use in ('Y','N')1
.....
Modern memory management and
gdb
can be quite complex for mainstream DBA/security staff and take up a
lot of time that could be best used elsewhere. My view is that if your security posture is such that in-memory rootkits
are an area of concern then it is worth working with a third-party supplier. McAfee and AppSecInc are the two market
leaders in this area for databases, and in my view the former has greater architectural knowledge and scope due
to their interests in many other infosec technology areas. Both of these companies have high expertise in RDBMS
security, but neither can protect against an attacker that has the root password. Since database security does depend
on OS security, it is worth considering how to defend against root access and privileged access control at *nix level.
Unix Privileged Access Control
First, Oracle DBA staff should not get BAU access to root or root commands through sudo, and Unix SAs should not
have EM access or database access. This is basic SoD (segregation of duty). This segregation should be effective both
