Oracle Security: SQL Injection in APEX CHECK_DB_PASSWORD

Advisory Text :

SQL Injection Vulnerability in Oracle APEX CHECK_DB_PASSWORD
#######################################################
This advisory
<http://www.red-database-security.com/advisory/oracle_apex_sql_injection
_check_db_password.html>

Name SQL Injection Vulnerability in Oracle CHECK_DB_PASSWORD
Systems Oracle APEX
Severity Medium Risk
Category SQL Injection
Author Alexander Kornbrust (ak at red-database-security.com)
Date 17 July 2007 (V 1.00)

Details
########
The function wwv_flow_security.check_db_password contains a SQL injection
vulnerability.
Oracle is using the ALTER USER command to change the password of a database
user without
doing an input validation of the password (=typical Oracle PL/SQL
programming fault).

APEX 3.0.1 is now doing an input validation on the user password. Apex
3.0.1 is used in
Oracle 11g.

Old, vulnerable code
####################
FUNCTION CHECK_DB_PASSWORD (P_USER_NAME VARCHAR2, P_PASSWORD VARCHAR2)
RETURN BOOLEAN IS
BEGIN
IF P_USER_NAME IS NULL OR P_PASSWORD IS NULL THEN
RETURN FALSE;END IF;
BEGIN
EXCEPTION
WHEN NO_DATA_FOUND THEN RETURN FALSE;END;
BEGIN
EXCEPTION
WHEN NO_DATA_FOUND THEN RETURN FALSE;END;
L_STMT:= 'ALTER USER "' || P_USER_NAME || '" IDENTIFIED BY "' ||
P_PASSWORD||'"';
EXECUTE IMMEDIATE L_STMT;

New code
########
Oracle is now doing a length check of the password (30 characters). Good
idea. I'm
interested to see if this is changed in 11g where passwords up to 50
characters are
allowed. One part of the input validation is stupid code. If the password
contains a
chr(34) Oracle throws an error message.
chr(34) is never executed. Even if this code would be executed this could
be bypassed
quite easily (e.g. chr( 34) or chr(34 ) or chr(35-1) or ...)

FUNCTION CHECK_DB_PASSWORD (P_USER_NAME VARCHAR2, P_PASSWORD VARCHAR2)
RETURN BOOLEAN IS
BEGIN
IF P_USER_NAME IS NULL OR P_PASSWORD IS NULL THEN
RETURN FALSE;END IF;
IF LENGTH(P_PASSWORD) > 30 OR INSTR(P_PASSWORD,'"') > 0 OR
INSTR(LOWER(P_PASSWORD),'chr(34)') > 0 THEN RETURN FALSE;END IF;

BEGIN
EXCEPTION
WHEN NO_DATA_FOUND THEN RETURN FALSE;END;
BEGIN
EXCEPTION
WHEN NO_DATA_FOUND THEN RETURN FALSE;END;
L_STMT:= 'ALTER USER "' || P_USER_NAME || '" IDENTIFIED BY "' ||
P_PASSWORD||'"';
EXECUTE IMMEDIATE L_STMT;

Affected Products
#################
This bug is fixed with 3.0.1 of APEX which is not part of the Critical
Patch Update July 2006. It's necessary to upgrade your APE installation to
3.0.1 or higher. Apex 3.0.1 is compatible with Oracle Application Express.

Patch Information
#################
This bug is fixed with Apex 3.0.1 or higher.

History
#######
07-may-2007 Oracle secalert was informed
07-may-2007 Bug confirmed
29-jun-2007 Oracle released APEX 3.0.1
17-jul-2007 Oracle published CPU July 2007 and recommends to update to
3.0.1
17-jul-2007 Red-Database-Security published this advisory

Analysis and CVE entries of the Oracle CPU
###########################################
<http://www.red-database-security.com/advisory/oracle_cpu_jul_2007.html>

(c) 2007 by Red-Database-Security GmbH

Security

IT News

Search

SecurityAlert Database

About SecurityAlert

ExploitAlert Database

SecurityReason Research

WLB Database

Send to WLB

About WLB

Security Audit

Schedule

Prices of services

Contact

SecurityReason IT News

SecurityAlert

World Laboratory of Bugtraq

ExploitAlert

Apache

PHP

Contact

About SecurityReason

Oracle Security: SQL Injection in APEX CHECK_DB_PASSWORD