Oracle vulnerabilities

Impact

Background

The Problem

• 2/20/03
  CAN 2003-0095
  CAN 2003-0096
  Multiple buffer overflows and format string vulnerabilities in Oracle 8 Database version 8.0.6, Oracle 8i Database version 8.1.7, Oracle 9i Database release 1 and 2, and Oracle 9i Application Server release 9.0.2 and 9.0.3 could allow a remote attacker to execute arbitrary commands on the underlying operating system. Exploitation of most of these vulnerabilities would require an attacker to know a valid login and password, but vulnerabilities in the Database Server authentication process and WebDAV could be exploited without a login and password.
• 12/27/02
  Vulnerabilities in Oracle 9i Application Server could allow disclosure of Java Server Page (.jsp) files or the contents of the WEB-INF directory. This could reveal information which could be useful to an attacker.
• 2/12/02
  CAN 2002-0559
  Multiple buffer overflows in the PL/SQL module could allow a remote attacker to execute arbitrary commands by sending long, specially crafted input in various HTTP header fields or form parameters.
• 12/26/01
  CAN 2001-1216
  A remote attacker could execute arbitrary commands or crash the service by sending a very long request for a help page. Normally, a valid login name and password are required to access any pages under the admin_ directory, but this is not the case for help pages, allowing exploitation of this vulnerability without authentication.
• 12/26/01
  CAN 2001-1217
  By requesting a help file containing character strings which have been URL encoded twice, it is possible for a remote attacker to escape from the web root and view arbitrary files on the server. Oracle iAS is only affected by this vulnerability when running on Windows platforms.
• 12/27/02
  Oracle 9i version 1.0.2.2 for Windows sets file permissions to Everyone: Full Control by default. These permissions could allow unauthorized local users to modify or delete files.
• 2/19/02
  CAN 2002-0562
  CAN 2002-0565
  Whenever a JSP page is requested, Oracle translates, compiles, and executes the page, creating three temporary files in the _pages directory in the process. These temporary files have predictable file names and can be accessed remotely. Furthermore, these temporary files contain, among other data, the source code of the original JSP file, which could reveal user IDs, passwords, and other sensitive information. Similarly, the globals.jsa file, if unprotected, could be used by a remote attacker to view sensitive information.
• 12/29/00
  If the Portal Listener and modplsql are installed without changing the default configuration, any user can access the administrative pages for those services.
• 12/29/00
  If public access is granted to PL/SQL procedures which access an Oracle database, it may be possible to request from the web server a URL which accesses these procedures. If this is the case, then unauthorized SQL statements could be executed on a back-end Oracle database.

Resolution

For Oracle 9i Application Server version 1.0.2.2 for Windows, if NTFS filesystems are in use, allow control of the Oracle home directory and all of its subdirectories only to the Administrators group.

To prevent remote users from viewing sensitive information in JSP pages or the globals.jsa file, enable access controls for the _pages directory and the globals.jsa file in the JSP sub-application's httpd.conf file, as described in Oracle Security Alert #28, item 2.

To enable access control on the Portal Listener and modplsql services, modify the wdbsvr.app file on WebDB/Portal so that the administrators variable is set to one or more users who are allowed administrator level access. Also, it is a good idea to change the path name which is used to access the administrative pages, which is /pls/admin_/gateway.htm by default.

There are two approaches to working around the last vulnerability. The first is to revoke public access to procedures which can potentially execute SQL commands, such as OWA, SYS, and DBMS. For modplsql, a second approach is to deny access to all URLs except those for procedures which have a legitimate reason to be called through the web interface. This can be done by modifying the plsql.conf file. An example of a rule which denies access to all procedures under the pls directory is the following:

<Location /pls/*/*>
  SetHandler pls_handler
  Order deny,allow
  Deny from all
</Location>

Where can I read more about this?