Oracle Reports versions 6.0, 6i, 9i, and 10g allows for unauthorized command execution.
c4d8f576853527f5797d50ebac8b56c69d36581500b4309070c285b0057679f2
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 https://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
https://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
https://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 https://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