A Security Hole in Oracle Application Server (Reports) and

W
Document Sample
scope of work template
							A Security Hole in Oracle Application Server
(Reports) and how to fix it

Version 1.1, 2005-09-11
A Security hole in the OAS (Reports) and how to fix it

A Security hole in the Oracle Application Server (Reports)
and how to fix it
White Paper about the security hole „destination name“ of Oracle Reports.



Content
Summary............................................................................................................................ 3
  The Error ........................................................................................................................ 3
  The Consequence........................................................................................................... 3
  The Solution ................................................................................................................... 3
Check by yourself: How you can reproduce the bug. ......................................................... 4
Explanation ........................................................................................................................ 5
Solutions ............................................................................................................................ 6
  The Statement of Oracle ................................................................................................. 6
  A half solution of the company Red Database Security.................................................... 7
  Trivadis Solution............................................................................................................. 8
    Extention of the workaround ..................................................................................... 11
Conclusion....................................................................................................................... 12
References ....................................................................................................................... 13




D. Nachbar Trivadis AG                                             2                                                      5.9.2005
A Security hole in the OAS (Reports) and how to fix it

Summary
The Error
Many Enterprises and Organisations are using Oracle Reports, a system to provide business
reports. These reports are generated dynamically and stored in the company’s intranet or
even published in an extranet environment.

An important functionality of Oracle Reports, the so called „destination name“ defines the
target directory on the reports server to store a given report to. This is especially important,
when a report is stored as “file report” for later reuse. This function is called by a standard
web browser. The target directory to store the reports to is defined by an URL string. Every
user can change this URL string manually. If a user does so, it is possible to overwrite
system files.

To defined the target directory a „get request“ is sent from the web browser to the Oracle
Application Server, where Oracle Reports is running. All parameters of this “get requests”
are sent as URL string in plain text to the server. They are visible for every user, who can
change the URL string to overwrite any system file. This concerns all these files and
directories that are accessible by the Oracle Application’s technical user.

The Consequence
OAS on Windows
If the Oracle Application Server with Oracle Reports runs on a Windows server, all files can
be overwritten, even such files as boot.ini. In this case the Windows server is not any more
usable and a reinstallation of the server is needed.
OAS on UNIX
If the Oracle Application Server with Oracle Reports runs on a UNIX server, all files
accessible by the Oracle user (technical user) can be overwritten, such as opmn.xml. The
Oracle Application Server is not any more usable. Even worse: If there is an Oracle
database running on the same server, the database and all data can be deleted.

This access cannot be detected and avoided by a firewall, because the standard HTTP /
HTTPS port is used.

The Solution
Trivadis experts have developed a solution to close this security hole. This solution restricts
the possibility to write reports to well defined directories. In this case, no system files are
overwritten.




D. Nachbar Trivadis AG                         3                                       5.9.2005
A Security hole in the OAS (Reports) and how to fix it


Check by yourself: How you can reproduce the bug.
The Bug occurs under following Reports Releases:

       •   Reports 6i
       •   Reports 9i
       •   Reports 10g Release 1 and Release 2

All tests are done under Oracle Application server release 9.0.2.x to 10.1.2.0.2. The Oracle
Internet Application Server Release 1.0.2.x was not concerned, since for this release the
Error Correction Support is exhausted.

Support-Matrix

Produktname             Error Correction              Extended Support   Extended
                        Support (ECS)                 (ES)               Maintenance
                                                                         Support (EMC)
Oracle Internet         30-June-2004                  30-June-2007       --
Application Server
1.0.2.2.x
Oracle Application      01-Juli-2005                  01-Juli-2008       --
Server 9.0.2.x bis
9.0.3.x
Oracle Application      31-Dezember-2006              31-Dezember-2009   31-Dezember-2008
Server 9.0.4
Source: Oracle Metalink, conditions August 2005

The following steps are recommended to verify the Bug:

Step 1:
Make a backup-copy of the $ORACLE_HOME/Apache/Apache/conf/httpd.conf file.

Step 2:
Examine whether the demo report test.rdf ($ORACLE_HOME/reports/samples/demo)
provided by Oracle is present and if the Report are in $REPORTS_PATH (if not available,
you can use any arbitrary report).
Call a Browser from any Client PC, which is able to access via HTTP to your middle tier,
with the following URL:

http://servername:port/reports/rwservlet?report=test.rdf&destype=file&desname=c:\oracle\
oas-fr\Apache\Apache\conf\httpd.conf&desformat=pdf

According to your operating system you must fix the parameter desname, under UNIX
systems e.g. desname=/u00/app/oracle/product/oas-fr/Apache/Apache/conf/httpd.conf.
Please note, that under UNIX systems the directory names and files are case sensitive.
Moreover you have to change in the parameter desname the target directory according to
your $ORACLE_HOME.
Step 3:


D. Nachbar Trivadis AG                            4                                5.9.2005
A Security hole in the OAS (Reports) and how to fix it

Open the httpd.conf file with a text editor (e.g. vi or notepad) and you will see that the
content of your httpd.conf is now a PDF-document and the Apache configurations are
overwritten.

Step 4:
Restore the httpd.conf file from your backup, which you hopefully made before☺.

With the parameter destype=file combined with the parameter desname=<target
directory>\<target file> you are able to overwrite not only configuration files but also to
overwrite executables (e.g. oracle, tnsping, and others).

Explanation
What happened?

The Oracle Reports Servlet as well as the Oracle Reports Server himself are started under a
specific operating system user and/or system account (under UNIX systems is this mostly
the user oracle and under Windows systems is this either the local system account or a
dedicated administrative user), thus these two processes are gaining all authorizations of
this user or system account.

The Oracle Reports parameter „desname” is intentionally kept as flexible as possible by
Oracle, so that you can dynamically create Reports on the file system of the OAS server.
Due to the fact that all Report processes inherit the authorizations of the operating system
user or the system account, these processes get the same authorizations on the file system
of the server.

Under UNIX systems this means that even files, which are in use, can be overwritten (e.g.
oracle Executable a.s.o.).

Due to the process architecture on Windows systems (files which are in use can not be
overwritten) all other files on the operating system to which the system user has access, can
be overwritten, so for example the boot.ini file.




D. Nachbar Trivadis AG                        5                                     5.9.2005
A Security hole in the OAS (Reports) and how to fix it


Solutions

The Statement of Oracle

The Author has at the moment a TAR (4550029.993) with Oracle Metalink Support open
and we already made a Web Conference for this purpose with the Support.

By Oracle is at the moment no Patch, One-Off Patch or Workaround provided for this Bug.
Rather following Statement was posted into the TAR:

Original unabridged statement of Oracle:

       „ Oracle Global Product Security has been aware of and actively working to
       fix the reported vulnerabilities in accordance with their severity level.
       Oracle provides all our customers with the same information in order to
       protect all customers equally. Any additional information or fixes will be
       made available to you through a Critical Patch Update Advisory or Security
       Alert.
       Security is a matter we take seriously at Oracle and our first priority is
       meeting customer needs and reducing your risk. When software flaws are
       discovered, Oracle responds as quickly as possible to help protect
       information secured by customers in Oracle-based information systems.
       Oracle's policy is to fix security vulnerabilities in severity order -- higher
       severity vulnerabilities are fixed as a priority over lower severity
       vulnerabilities.
       Oracle encourages our customers to contact us as soon as they discover
       security vulnerabilities. We believe the most effective way to protect
       customers is to avoid disclosing or publicizing vulnerabilities before a patch
       or workaround has been developed. We are disappointed when any details
       of Oracle product security vulnerabilities are released to the public before
       patches can be made available. „

A possible solution of the problem was recommended by the author to the Oracle Support.
The solution is based on a change within the rwservlet-Class (oracle.reports.server.DesFile).
The recommended change is based on the base idea of the rwservlet-class
oracle.reports.server.DesCache, in which a parameter „cacheDir“ exist. With this Parameter
you can define the location of the target directory for the generation of the reports and
therefore you can limit it.




D. Nachbar Trivadis AG                       6                                      5.9.2005
A Security hole in the OAS (Reports) and how to fix it

This change could look like this:

. . .
<destination destype="file" class="oracle.reports.server.DesFile">
       . . .
      <property name="desDir" value="C:\rep_dest"/>
       . . .
</destination>
. . .

This implementation changes the actual parameter “desname” containing only the
destination file for the reports generation (but not the target directory). The functionality of
Reports would not be influenced, it would only cause the necessary security for your file
system.

At the moment, there is no reaction for Oracle to this suggestion.

A half solution of the company Red Database Security
This Bug is at present a much discussed topic, which was started by the Consulting
Company Red-Database-Security (here of Mr. Alexander Kornburst) and published under
Heise-news (see Heise-News from 20.07.2005
http://www.heise.de/newsticker/meldung/61861). Under these Heise-News a reference to a
Bullet of the Re-Database-Security can be found, in which the Bug is shortly described and
also a possible workaround is provided.

Excerpt of the workaround from
http://www.red-database-security.com/advisory/oracle_reports_overwrite_any_file.html:

RewriteLog /anywhere/rewrite.log
RewriteEngine On
RewriteRule (.*)desname(.*)$ /forbidden.htm [R] [NC]

The above mentioned Workaround was tested under following OAS Releases:
•  Oracle Application Server 9.0.2.0 / 9.0.4.0 (inclusive CPUJul2005 Patch) / 9.0.4.1 /
   9.0.4.2 and 10.1.2.0.2 – Editions: Enterprise Edition and Forms & Reports Standalone
and under following operating systems:
•   Windows XP
•   Windows 2000 Advanced Server
•   Redhat AS 2.1 / 3.0
•   UnitedLinux 1.0
•   Solaris 5.8

As the company Red Database Security stated, the workaround should avoid the generation
of a report. Instead of generating the report, the request should be redirected to the
forbidden.htm page. This was during our tests not the case. According the log file, the
called URL is not affected by the RewriteRule.




D. Nachbar Trivadis AG                          7                                       5.9.2005
A Security hole in the OAS (Reports) and how to fix it


Relevant excerpt (IP, Timestamp Information, etc.) are not printed here):

. . . init rewrite engine with requested uri /reports/rwservlet
. . . applying pattern '(.*)desname(.*)$' to uri '/reports/rwservlet'
. . . pass through /reports/rwservlet

Even after detailed tests, we are not able to reproduce the workaround’s functionality. The
author A. Kornbrust has overlooked, that the pattern in the RewriteRule is not part of the
URI; it is part of the URL’s query string. All Report calls are never treated by the
RewriteRule and therefore unchanged directed to the Reports servlet.

We recommend not using the workaround published by Red Database Security because it
does not change the effect for the reports bug „desname“.

Trivadis Solution

The developed workaround is based on the Apache module mod_rewrite, which is a
standard module in the Oracle HTTP Server (OHS) that is activated and ready to use.

The module mod_rewrite is often called the „Swiss Army Knife of URL Manipulation“. This
module provides you nearly unexpected features for manipulation of URL’s.
The module is based on a rule based engine (regular expression) and therefore you can
rewrite URL’s on the fly.

Workflow of mod_rewrite:


                                                      Current URL


                           RewriteCond


                                    TestString                       CondPattern




             RewriteRule             Pattern                         Substitution




                                                     Rewritten URL



The number of RewriteCond is not limited to a single one as shown in the workflow; you
can combine many RewriteCond’s in one RewriteRule.

The RewriteCond contains basically two parts, the TestString and the CondPattern.



D. Nachbar Trivadis AG                           8                                  5.9.2005
A Security hole in the OAS (Reports) and how to fix it

The TestString is normally a variable, e.g. %{HTTP_USER_AGENT} or
%{QUERY_STRING} (see Apache Documentation for a complete description
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html).

The CondPattern are pure regular expressions with a few extensions (see
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html) and an optional flag, e.g. [NC] for
no case or [OR] for a logical or condition (the default is a logical and condition)

The RewriteRule contains also to parts, the Pattern and the Substitution.

The Pattern contains the actually rule for the rewriting process of the URL’s. The pattern is
normally a regular expression, which defines the condition for which string the rule should
check and the corresponding substitution for rewriting. In case the rule match for the URL a
rewrite will be processed directly or if you have additionally defined RewriteCond’s they
will processed at first.

The Substitution contains in which way the URL will be rewritten, if the URL match with
the RewriteRule pattern and the additionally RewriteConds. For the substitution it is also
possible to use query strings. Moreover the substitution can contain additionally flags, e.g.
[R] for redirect or [QSA] for query string append.

To implement the RewriteRule are two ways possible. First way, place in the directory an
.htaccess file which contains the RewriteRules or second way implement the RewriteRules
directly in your httpd.conf file.

The implementation via .htaccess is not possible, because the Report calls
(/reports/rwservlet) are not directives or locations. As a matter of fact the Report calls
(/reports/rwservlet) are „OC4Jmount-Points“, which are not physical directories.

The Workaround

Excerpt from httpd.conf under Win32:

RewriteLog C:\Oracle\as-fr-9.0.4\Apache\Apache\logs\rewrite_din.log
RewriteLogLevel 9
RewriteEngine On
RewriteCond %{QUERY_STRING} (.*)destype=file(.*) [NC]
RewriteCond %{QUERY_STRING} (.*)desname=(.*) [NC]
RewriteCond %{QUERY_STRING} !(.*)desname=c:\\rep_des\\[A-Za-z0-9](.*)
[NC]
RewriteRule (.*)reports(.*)$ /forbidden.htm [R] [NC]

Excerpt from httpd.conf under UNIX-Systems:

RewriteLog /u00/app/oracle/product/as-fr-9.0.4/Apache/Apache \
          /logs/rewrite_din.log
RewriteLogLevel 9
RewriteEngine On
RewriteCond %{QUERY_STRING} (.*)destype=file(.*) [NC]
RewriteCond %{QUERY_STRING} (.*)desname=(.*) [NC]
RewriteCond %{QUERY_STRING} !(.*)desname=/rep_des/[A-Za-z0-9](.*) [NC]



D. Nachbar Trivadis AG                          9                                       5.9.2005
A Security hole in the OAS (Reports) and how to fix it

RewriteRule (.*)reports(.*)$ /forbidden.htm [R] [NC]

For demonstration and proof that the implemented RewriteRule is really working, in the
above shown configuration was set the Option RewriteLogLevel 9 (highest logging level).
This you should avoid in a production environment, here should be a log level between 3
and 5 ok or disable the log level completely.

How does the Workaround work?

Each HTTP request on the Oracle HTTP Server will now be sent through the mod_rewrite.
First it is checked if the pattern in the RewriteRule matches with the request URL:

RewriteRule (.*)reports(.*)$ /forbidden.htm [R] [NC]

In this RewriteRule checks if in the URI part of the URL request the string „reports“ is
available, if yes, the request will be directed to the following RewriteCond:

RewriteCond %{QUERY_STRING} (.*)destype=file(.*) [NC]

This condition searches in the query string part of the URL request if a string “destype=file”
is available. This search will be done non case sensitive. If this is true, the second
RewriteCond will be fired:

RewriteCond %{QUERY_STRING} (.*)desname=(.*) [NC]

This condition search in the query string part of the URL request if a string “desname=” is
available. This search will be done non case sensitive. If this is true, the third RewriteCond
will be fired.

RewriteCond no. 3 under UNIX-Systems:
RewriteCond %{QUERY_STRING} !(.*)desname=/rep_des/[A-Za-z0-9](.*) [NC]

RewriteCond no. 3 under Windows-Systems:
RewriteCond %{QUERY_STRING} !(.*)desname=C:\\rep_des\\[A-Za-z0-9](.*)
[NC]

In the last RewriteCondition a negative regular expression will be processed. This regular
expression checks which query strings of the expression „(.*)desname=/rep_des/(.*)“ are
not equal. This check is done with the option non-case-sensitive. This means, as soon as a
query string equal „desname=<Reports_Destination_Directory> is found the expression
does not match and the Report generation will be processed. If the expression detects a
query string that is not equal then the RewriteRule will be fired and the URL will be
redirected to the forbidden.htm web page. Please note that under Windows systems you
have to define the regular expression in a special manner, because the backslash “\” is a
reserved string and you have to mask the backslash with a backslash.
Moreover is for security reasons an additional regular expression „[A-Za-z0-9]“
implemented to avoid a bypass of the RewriteCond with a faked target directory
“rep_des/../u00/app/oracle/product/as-fr-9.0.4/bin/“. This force that on the first place after




D. Nachbar Trivadis AG                        10                                      5.9.2005
A Security hole in the OAS (Reports) and how to fix it

the reports destination directory an alphanumeric sign have to follow. Therefore a bypass
with “../” or the usage of “%” is not possible.
This regular expression causes two restrictions in the practical use:

   1. The creating reports (PDF, TXT, XML-documents a.s.o.) must contain on the first
      place of the filename an alphanumeric sign.
   2. In the defined reports destination directory are no subdirectories allowed! If
      subdirectories exist in the reports destination directory the RewriteCond can easily
      bypassed!


RewriteRule (.*)reports(.*)$ /forbidden.htm [R] [NC]

The URL will be rewritten and redirected to the forbidden.htm webpage.

This sequence can be proven with the RewriteLog File:

init rewrite engine with requested uri /reports/rwservlet
applying pattern '(.*)reports(.*)$' to uri '/reports/rwservlet'
RewriteCond:
input='report=test.rdf&desname=C:\rep_forbidden\test_din.pdf \
&destype=file&desformat=PDF' pattern='(.*)destype=file(.*)' => \ matched
RewriteCond:
input='report=test.rdf&desname=C:\rep_forbidden\test_din.pdf \
&destype=file&desformat=PDF' pattern='(.*)desname=(.*)' => matched
RewriteCond:
input='report=test.rdf&desname=C:\rep_forbidden\test_din.pdf \
&destype=file&desformat=PDF' \ pattern='!(.*)desname=c:\\rep_dest\\(.*)'
\ => matched
rewrite /reports/rwservlet -> /forbidden.htm
explicitly forcing redirect with http://oassrv/forbidden.htm
escaping http://oassrv/forbidden.htm for redirect
redirect to http://oassrv/forbidden.htm?report=test.rdf \
&desname=C:%5crep_des%5ctest_din.pdf&destype=file \ &desformat=PDF
[REDIRECT/302]

Extension of the workaround
On the beginning of the section, we promised you, that you can use this workaround for
every Reports server (service) on your application server and so you should be able to
define for every Reports server an own destination directory.

What to do if two additional Reports server are used?

We copy the already existing Rewrite-Block and extent the RewriteRule by defining another
RewriteCond to check the server name. The original RewriteRule must also be extended.
This extension depends on the number of additional Reports server:




D. Nachbar Trivadis AG                      11                                    5.9.2005
A Security hole in the OAS (Reports) and how to fix it

RewriteLog /u00/app/oracle/product/as-fr-9.0.4/Apache/Apache \
/logs/rewrite_din.log
RewriteLogLevel 9

# RewriteRule for the Default Reports Server (In-Process)
RewriteEngine On
RewriteCond %{QUERY_STRING} !(.*)server=rep_server1(.*) [NC] [OR]
RewriteCond %{QUERY_STRING} !(.*)server=rep_server2(.*) [NC]
RewriteCond %{QUERY_STRING} (.*)destype=file(.*) [NC]
RewriteCond %{QUERY_STRING} (.*)desname=(.*) [NC]
RewriteCond %{QUERY_STRING} !(.*)desname=/rep_des/[A-Za-z0-9](.*) [NC]
RewriteRule (.*)reports(.*)$ /forbidden.htm [R] [NC]

# RewriteRule for Reports Server rep_server1
RewriteEngine On
RewriteCond %{QUERY_STRING} (.*)server=rep_server1(.*) [NC]
RewriteCond %{QUERY_STRING} (.*)destype=file(.*) [NC]
RewriteCond %{QUERY_STRING} (.*)desname=(.*) [NC]
RewriteCond %{QUERY_STRING} !(.*)desname=/rep_des_server1/[A-Za-z0-
9](.*) [NC]
RewriteRule (.*)reports(.*)$ /forbidden.htm [R] [NC]

# RewriteRule for Reports Server rep_server2
RewriteEngine On
RewriteCond %{QUERY_STRING} (.*)server=rep_server2(.*) [NC]
RewriteCond %{QUERY_STRING} (.*)destype=file(.*) [NC]
RewriteCond %{QUERY_STRING} (.*)desname=(.*) [NC]
RewriteCond %{QUERY_STRING} !(.*)desname=/rep_des_server2/[A-Za-z0-
9](.*) [NC]
RewriteRule (.*)reports(.*)$ /forbidden.htm [R] [NC]


Conclusion
With really simple mechanism you are able to eliminate The Oracle reports bug. And this
implementation offers you the possibility of an extension for Oracle Reports, with which
you can define for every Reports server an own destination directory.

But never the less, it would be the best solution, if Oracle takes note of my suggestion and
would implement directly the necessary changes within the rwservlet-Class.

And last but not least, you are closer to Oracle’s Slogan „Unbreakable“, with a little help
from Trivadis.

Secured Reports generation wishes you Dirk Nachbar

Trivadis SA                                    Mail:   dirk.nachbar@trivadis.com
Rue Marterey 5                                 Tel.:   + 41-21 321 47 00
CH-1005 Lausanne                               Fax:    + 41-21 321 47 01
http://www.trivadis.com




D. Nachbar Trivadis AG                       12                                      5.9.2005
A Security hole in the OAS (Reports) and how to fix it

References
Title                                        ISBN / Link
Apache HTTP Server Documentation             http://httpd.apache.org/docs/1.3/
Oracle Application Server 9.0.2              http://download-
Documentation                                west.oracle.com/docs/cd/A97329_01/index.htm
Oracle Application Server 9.0.4              http://download-
Documentation                                west.oracle.com/docs/cd/B10464_01/index.htm
Mastering Regular Expression, Jeffrey E.F.   ISBN: 1-56592-257-3
Friedl, O’Reilly Verlag
Oracle Desupport Notice Oracle Internet      Doc-ID: 231674.1
Application Server 1.0.2.2.x
Oracle Desupport Notice Oracle               Doc-ID: 273213.1
Application Server 9.0.2.x / 9.0.3.x
Oracle Desupport Notice Oracle               Doc-ID: 295948.1
Application Server 9.0.4.x




D. Nachbar Trivadis AG                       13                                5.9.2005

						
Related docs