Pete Finnigan's Oracle Security Weblog

I just came across an interesting thread on ORACLE-L discussing the versions of DBMS_SUPPORT that are available in the database. The thread has not made it to the archives yet on freelists.org but should appear soon?

The thread asks the question about the version of this useful package. The poster demonstrated the confusion with this, i.e.

SQL> select sys.dbms_support.package_version from dual;

PACKAGE_VERSION
------------------------------------------------------------------------
DBMS_SUPPORT Version 1.0 (17-Aug-1998) - Requires Oracle 7.2 - 8.0.5

SQL>

The version of Oracle is:-

SQL> select * from v$version;

BANNER
------------------------------------------------------------
Personal Oracle9i Release 9.2.0.1.0 - Production
PL/SQL Release 9.2.0.1.0 - Production
CORE 9.2.0.1.0 Production
TNS for 32-bit Windows: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production

SQL>

Hmmm, a slight issue? The version function says that this package should only be used between versions 7.2 and 8.0.5. What’s the score? The thread goes on to ask if there is a newer version of this package and what it might include such as showing the name of a trace file. Jared goes on to agree about the versions and Paul suggests that the package was not even shipped with version 8iR3.

So what is the issue with this package? This is an un-documented package apart from numerous metalink notes that mention it. The package should not be installed by default and should only be installed if you are instructed to do so by Oracle support. Many DBA's install it anyway.

So what is the security angle? Well if a package is not even shipped with one version (I think this was recorded as a mistake though rather than deliberate). A package that is not supported and is undocumented then it should not normally be there and in use. What can we use the package for besides reporting its version? - It can be used to get your own SID and also to turn on trace, either with extended trace or not. I include how to use this package in my paper all about all of the ways to turn on trace. To some using trace is a must but to a security person being able to set trace and also to set trace for another session is a security risk. Trace can be used to extract all sorts of application structure and also to steal critical data from the database and configurations. Therefore any method of setting trace should be restricted.

I would recommend using my script who_can_access.sql to see which users and roles can access this package. Let's see for a default install of this package:

who_can_access: Release 1.0.1.0.0 - Production on Sat Nov 13 19:49:29 2004
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.

NAME OF OBJECT TO CHECK [USER_OBJECTS]: DBMS_SUPPORT
OWNER OF THE OBJECT TO CHECK [USER]: SYS
OUTPUT METHOD Screen/File [S]: S
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]:

Checking object => SYS.DBMS_SUPPORT
====================================================================



PL/SQL procedure successfully completed.


For updates please visit /tools.htm

SQL>

As you can see the default is that no users can access this package, keep it this way. If any user has been granted access to this package revoke it, if its installed then remove it, unless Oracle support ask you to use it.