|
Services
Information
Company |
SQL Injection via mod_plsql
Analysis A typical mod_plsql URL is http://192.168.2.22/pls/test/x.helloworld. This sample URL executes the procedure helloworld of the user X. To avoid accessing (mighty) packages which are granted to public, Oracle is blocking the access of procedures / packages containing the following (hardcoded) strings and user defined exclusions (exclusion_list): 'sys.%' 'dbms\_%' 'utl\_%' 'owa\_%' 'owa.%' 'htp.%' 'htf.%'Oracle generates an anonymous PL/SQL-block containing the procedure name (e.g. x.helloworld) to compare the procedure name from the URL with the values from the exclusion list. You can see the entire generated PL/SQL source by adding the following strings to the WDBSVR.APP [WVGATEWAY] debugModules=all LoggingLevel=Debug All debug information will be stored in the $ORACLE_HOME/Apache/modplsql/log/<DAD>/<PORT>
An extract of the generated PL/SQL code is here:
[...]
if (owa_match.match_pattern('x.helloworld', simple_list__, complex_list__, true)) then
rc__ := 2;
else
null;
null;
x.helloworld;
[...]
By sending a specially crafted procedure name, containing a ")", it is possible to bypass the package owa_match.The workaround with URLRewrite blocks all requests containing closed brackets. Affected Products All Oracle products running mod_plsql (e.g. Application Server or HTTP/OHS running from the database) Patch Information This bug is NOT fixed with Critical Patch Update January 2006. David Litchfield posted a workaround with URLRewrite with mod_plsql. Workaround for Oracle mod_plsql Use URLRewrite to block potential dangerous URLs containing a ")".
RewriteEngine on
RewriteCond %{QUERY_STRING} ^.*\).*|.*%29.*$
RewriteRule ^.*$ http://127.0.0.1/denied.htm?attempted-attack
RewriteRule ^.*\).*|.*%29.*$ http://127.0.0.1/denied.htm?attempted-attack
Problems with this workaroundIntegrigy recommends in the Security Analysis of the mod_plsql security bug like Oracle in their press statements NOT to use this workaround. After reading the analysis from Integrigy I agree with their recommendation. Another Workaround Vladimir Zakharychev from Webrecruiter informed me about another workaround for the mod_plsql SQL Injection issue. Setting the value "always_describe" (up to 3.0.9.x.x) or "PlsqlAlwaysDescribeProcedure" (higher than 3.0.9.x) to ON in the dads.conf protects from the SQL Injection vulnerability in mod_plsql. What is PlsqlAlwaysDescribeProcedure? PlsqlAlwaysDescribeProcedure specifies whether mod_plsql should describe a procedure before trying to execute it. If this is set to "On", then mod_plsql will always describe a procedure before invoking it. Otherwise, mod_plsql will only describe a procedure when its internal heuristics have interpreted a parameter type incorrectly. If PlsqlAlwaysDescribeProcedure is enabled, Oracle tries to describe every PL/SQL procedure. If a hacker injects pl/sql code, Oracle tries to describe this specially crafted string but fails because this procedure does not exist. Potential problems with this workaround Using this switch could have a negative impact on the application performance. History 26-oct-2005 David Litchfield from NGS informed Oracle 7-nov-2005 David Litchfield informed the NISCC 25-jan-2006 David Litchfield posted a workaround for this unpatched vulnerability 26-jan-2006 Red-Database-Security released this analysis of the vulnerability 27-jan-2006 Info added how to enable the mod_plsql debugging mode 1-feb-2006 Another Workaround via PlsqlAlwaysDescribeProcedure + advisory from Integrigy added 4-feb-2006 Oracle FAQ for this vulnerability added 18-apr-2006 Oracle released CPU April 2006 which contains a fix for this problem Links
© 2006 by Red-Database-Security GmbH - last update 18-apr-2006 |
Oracle MOD_PLSQL |
