Dear Bugtraq Reader

3 months ago (15-april-2005) I informed the Oracle Security Team (secalert_us@oracle.com) that I will publish bug details if the bugs are not fixed with the next critical patch update (CPU July 2005). I know that Oracle products are complex and a good patch quality need some time. That's why I offered Oracle additional time if 3 months are not sufficient for fixing the bugs. Oracle never asked for more time.

Oracle's behaviour not fixing critical security bugs for a long time (over 650 days) is not acceptable for their customers. Oracle put their customers in danger. At least one critical vulnerability can be abused from any attacker via internet.

I decided to publish these vulnerabilities because it is possible to mitigate the risk of these vulnerabilities by using the workarounds provided in the advisories.


Kind Regards

 Alexander Kornbrust

 www.red-database-security.com

#################################################

Red-Database-Security GmbH  - Oracle Security Advisory

Run any OS Command via unauthorized Oracle Reports


 Name                Run any OS Command via unauthorized Oracle Reports
 Systems Affected    Oracle Reports 6.0, 6i, 9i, 10g
 Severity            High Risk 
 Category            OS command execution
 Vendor URL          http://www.oracle.com 
 Author              Alexander Kornbrust (ak at red-database-security.com) 
 Date                19 July 2005 (V 1.00) 
 Advisory            AKSEC2003-014
 Inital bug report   663 days ago
 Advisory-URL       
http://www.red-database-security.com/advisory/oracle_reports_run_any_os_command.
html


Details
#######
Oracle Reports is Oracle's award-winning, high-fidelity enterprise reporting
tool. It enables businesses to give immediate access to information to all
levels within and outside of the organization in an unrivaled scalable and
secure environment.
Oracle Reports, a component of the Oracle Application Server, is used by Oracle
itself for the E-Business Suite. Many large customers are using Oracle Reports
as reporting tool for their enterprise applications.

Oracle Reports starts reports executables (*.rep or *.rdf) from any directory
and any user on the application server. These reports are executed as user
Oracle or System (Windows). An attacker which is able to upload a specially
crafted reports executable to the application server is able to run any OS
command or read and write text files on the application server (e.g. wdbsvr.app
containing Oracle passwords). He can overtake the application server. The upload
could be done via Webdav (Part of the Oracle Application Server), Webutil, SMB,
SAMBA, NFS, FTP, ...

By using the report parameter with an absolute path it is possible to execute
reports executables from ANY directory and ANY user.


Testcase
########
1. Create or modify a simple report and add an ORA_FFI call to run OS commands
or a TEXT_IO call to create or read text files on the application server.
Details how to call OS Program/Command from Reports (Metalink ID: 181086.1) or
Read and Write Textfiles Using TEXT_IO (Metalink: 33247.1) are available on
Oracle Metalink.

2. Generate the reports executable (e.g. hacker.rdf or hacker.rep) for the
destination platform (e.g. Linux, Solaris, Windows, ...)

3. Copy the reports executable hacker.rdf to a directory on the Oracle
Application Server
(e.g. via SMB, file upload, Webdav, Samba, NFS, Webutil, FTP, ...)

4. Run the report "hacker.rdf" as user Oracle and specify an absolute path for
the reports executable
http://myserver.com:7779/reports/rwservlet?server=repserv+report=/tmp/hacker.rdf
+destype=cache+desformat=PDF

5. The host command is executed (ORA_FFI) or a file could be read/write
(TEXT_IO) as user Oracle (Unix) or user SYTEM (Windows).



Workarounds
###########
Available at http://www.red-database-security.com/advisory/oracle_reports_run_any_os_command.html


Patch Information
#################
This bug is NOT FIXED with Critical Patch Update July 2005 (CPU July 2005). It
seems that Oracle is NOT INTERESTED to fix this issue and provide patches.



History
#######
25-sep-2003 Oracle secalert was informed

26-sep-2003 Bug confirmed

15-apr-2005 Red-Database-Security informed Oracle secalert that this
vulnerability will publish after CPU July 2005 Red-Database-Security offered 
Oracle more time if it is not possible to provide a fix ==> NO FEEDBACK.

12-jul-2005 Oracle published CPU July 2005 without fixing this issue

19-jul-2005 Red-Database-Security published this advisory




© 2005 by Red-Database-Security GmbH - last update 19-july-2005