Details for Oracle’s April 2016 Critical Patch Update

David Litchfield
(​
dlitchfield@google.com​
)
22nd April 2016

Oracle released a Critical Patch Update or CPU​ on Tuesday 19th April, 2016 fixing over 136
[1]​
issues. This document details the issues reported by David Litchfield

Preauth SQL Injection in eBusiness Suite 12.1 and 11.5 (CVE­2016­3466)

The web server has a JSP page named csfwcpnt.jsp which takes an SQL query via a parameter
called “query”. This SQL query executes with the privileges of the APPS user (which can
execute SQL as the SYS user (see S0637799)). No username or password is required to exploit
this flaw and it should be considered as critical. Oracle has given it a score of 9.1 under CVSS
3.0 ​
[2]

Whilst the CPU is undergoing testing before being deployed, it is strongly urged that customers
either remove this JSP or use a location, mod_rewrite directive to deny access.

Limited PL/SQL Injection in eBusiness Suite 12.2, 12.1 and 11.5 (CVE­2016­0697)
The FND_WEB_SEC PL/SQL package contains two functions INT_CPASS_SYS and
INT_CPASS_ORA that both internally call the CONN_INSIDE_SYS procedure which executes
the following SQL:

SQL:='ALTER USER ' || P_USER || ' IDENTIFIED BY ' || P_PASS;

This can be used to change the password for any user and, by injecting via the P_PASS
parameter, modify other aspects of the user, for example, unlocking them. The SQL is executed
via DBMS_SYS_SQL and to accommodate this the APPS user has been given the EXECUTE
privilege on this package. Anyone with EXECUTE privileges on DBMS_SYS_SQL can execute
SQL as the SYS user by specifying 0 for the USER_ID parameter of the PARSE_AS_USER.
This is a secondary issue to the limited PLSQL injection and was tracked as ​ S0637799​ but it
appears, whilst Oracle has fixed this, they have not included it in their public risk matrix.

When combined with the pre­auth SQL injection (CVE­2016­3466) this presents a serious threat
to the security of an eBusiness Suite system. Applying the CPU will resolve these issues.

Failures in Audit system in the Oracle RDBMS 12.1, 11.2 and earlier
AUDIT NOT EXISTS fails to capture attempts to execute a procedure that does not exist either
because the user does not have the execute privilege on it or because the procedure does not
actually exist (CVE­2016­0690). If a DBA wants to capture attempts to execute procedures
where the user does not have the execute privilege we must also add:

AUDIT EXECUTE PROCEDURE WHENEVER NOT SUCCESSFUL;

However, both AUDIT NOT EXISTS and AUDIT EXECUTE PROCEDURE WHENEVER NOT
SUCCESSFUL fail to capture attempts when a procedure actually doesn't exist. For example

EXEC AFGSFGAFSAGSF;

leaves nothing in the audit trail.

Further, if a "missing" (due to no execute privilege) function is within a SELECT query the name
of the function is not logged but the name of the table in the query (CVE­2016­0691).

SQL> revoke execute on dbms_aw from public;

Revoke succeeded.

SQL> connect david/**********************

Connected.
SQL> select * from dual where dummy = to_char(dbms_aw.interp('sleep 5'));
select * from dual where dummy = to_char(dbms_aw.interp('sleep 5'))
*
ERROR at line 1:
ORA­00904: "DBMS_AW"."INTERP": invalid identifier

SQL> connect / as sysdba

Connected.
SQL> select action, action_name, returncode, obj_name from sys.dba_audit_trail;

3 SELECT 2004 DUAL

Being alerted to potential security breaches of a database server is aided considerably by

enabling auditing of failures so, now that these issues have been fixed, DBAs will have a much
better picture of what is happening to their databases.

[1] ​
http://www.oracle.com/technetwork/security­advisory/cpuapr2016v3­2985753.html
[2] ​
https://www.first.org/cvss/calculator/3.0