Oracle Patchset 10.2.0.5.0 impact on password enabled roles

Question

Oracle Patchset 10.2.0.5.0 (as well as 11.1.0.7 according to Oracle Support note 745407.1) will affect your password enabled roles security if you grant password enabled role to a user as a DEFAULT role (this users - like firecall ids - don't have to provide password to have this role active after logon). It turns out this is the only impact contrary to Oracle Support (Metalink) note 745407.1 stating that roles granted to other roles are affected as well. After I read the note I've worked with my DBA to assess possible damage to the application I support. Below are the results that I hope might help other people to assess and fix their situation as well (Please don't do the "fix" recommended by note 745407.1 which is to "remove password protection from the role" as this will trash your application security) :
BEFORE THE PATCH:
SQL*Plus: Release 10.1.0.4.2 - Production on Mon Sep 20 14:45:13 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
SQL# -- Create Ordinary Oracle Role
SQL# create role ORACLE_ROLE;
Role created.
SQL#
SQL# -- Create Password Authenticated Role
SQL# create role PASSW_AUTH_ROLE identified by xxxxxxx;
Role created.
SQL#
SQL# -- Create Another Ordinary Role to be granted to ORACLE_ROLE
SQL# create role ROLE_TO_OTHER_ROLE;
Role created.
SQL#
SQL# GRANT ROLE_TO_OTHER_ROLE TO ORACLE_ROLE;
Grant succeeded.
SQL#
SQL# -- Create Secure Application Role
SQL# create role SECURE_APP_ROLE identified using sec_roles;
Role created.
SQL# -- sec_roles procedure
SQL# CREATE OR REPLACE procedure sec_roles AUTHID CURRENT_USER
2 AS
3
4 BEGIN
5 DBMS_SESSION.SET_ROLE('secure_app_role');
6 END;
7 /
Procedure created.
SQL#
SQL# grant execute on SEC_ROLES to public;
Grant succeeded.
SQL#
SQL# SQL# -- Create User Account
SQL# CREATE USER app_user IDENTIFIED BY "xxxxxxx"
2 DEFAULT TABLESPACE "USERS01"
3 TEMPORARY TABLESPACE "TEMP01";
User created.
SQL# GRANT CONNECT, ORACLE_ROLE, PASSW_AUTH_ROLE, SECURE_APP_ROLE to app_user;
Grant succeeded.
SQL# ALTER USER app_user DEFAULT ROLE ALL;
User altered.
connect app_user@XXXXXX
Enter password: *********
Connected.
select * from session_roles;
ROLE
CONNECT
ORACLE_ROLE
ROLE_TO_OTHER_ROLE
PASSW_AUTH_ROLE
Note here that SECURE_APP_ROLE does not appear in the list of active session roles, which is in accordance with Oracle Support (Metalink) note 745407.1 saying that this is the case starting with versions 11.1.0.7 and 10.2.0.4 for Secure Application Roles.
AFTER THE PATCH APPLIED:
connect app_user@XXXXXX
Enter password: *********
Connected.
select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for Solaris: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
SQL# show user
USER is "APP_USER"
SQL#
SQL# select * from session_roles;
ROLE
CONNECT
ORACLE_ROLE
ROLE_TO_OTHER_ROLE
As expected password enabled role PASSW_AUTH_ROLE disappeared from the list of the roles enabled by default. Contrary to the expectations ROLE_TO_OTHER_ROLE that is granted to ORACLE_ROLE but not directly to the user is still active. As it turns out that is not the last surprise.
In order to test other possible combinations of roles granted to other roles I've created two other roles:
create role role_to_other_role_2;
Role created.
SQL# create role PASSW_AUTH_ROLE_2 identified by xxxxxxxx;
Role created.
SQL# grant passw_auth_role_2 to oracle_role
Grant succeeded.
SQL# grant PASSW_AUTH_ROLE_2 to PASSW_AUTH_ROLE
Grant succeeded.
SQL# grant role_to_other_role_2 to passw_auth_role;
Grant succeeded.
Surprisingly after logon password enabled role PASSW_AUTH_ROLE_2, granted through non-password enabled role ORACLE_ROLE, is active without need to provide password to set PASSW_AUTH_ROLE_2 role, which kind of defeats the purpose of Oracle security change in the first place.
connect app_user@XXXXXX
Enter password: *********
Connected.
select * from session_roles;
ROLE
CONNECT
ORACLE_ROLE
ROLE_TO_OTHER_ROLE
PASSW_AUTH_ROLE_2
Also if we set other password enabled role PASSW_AUTH_ROLE all roles granted to that role become active roles:
set role passw_auth_role identified by xxxxxxxx;
Role set.
select * from session_roles;
ROLE
PASSW_AUTH_ROLE
PASSW_AUTH_ROLE_2
ROLE_TO_OTHER_ROLE_2
As we can see this Oracle attempt to solidify role based security leaves some holes, and documentation is confusing and misleading. I expect that there will be more interventions coming in the future and we will need to verify with Oracle if they intend to do changes with role based security in the future that might have much greater impact on applications security models, and potentially cause unwanted downtime.
Finaly the query to figure out if you are potentially affected is:
select B.grantee, A.role, B.default_role
from dba_roles A, dba_role_privs B
where A.password_required = 'YES'
and A.role = B.granted_role
and B.default_role = 'YES';

Answer 1

I think, we are also facing this problem. Please let me know if any one has got any kind of FIX for this ?
we have just migrated from 10.2.0.4.0 to 10.2.0.5.0. All of a sudden set of code stopped working.
Query runs before setting up ROLE and similer query gives error after setting up the ROLE. If we don’t set the ROLE, both queries work fine.
======= Code =====
SELECT granted_role
FROM DBA_ROLE_PRIVS
WHERE grantee = '501280629'
AND granted_role IN ('PICAMG','PICAUS', 'PICAVW', 'PICAOP', 'PICADB')
AND ROWNUM = 1 ----> this query works before setting up ROLE
SET ROLE PICADB IDENTIFIED BY XXXXX ----> setting up ROLE
SELECT granted_role
FROM DBA_ROLE_PRIVS
WHERE GRANTEE = '501280629'
AND granted_role IN ('PICAMG','PICAUS', 'PICAVW', 'PICAOP', 'PICADB') ----> this query does work after setting up ROLE
Thanks
Suraj