Phone
800-766-1884

Oracle Tips by Burleson

Listener External Procedures

One of the features introduced to the database in Oracle 8 is the ability to call external C programs from within the database. This was done to extend the functionality of the PL/SQL routines that can be written in C to perform complex calculations, such as mathematical modeling, or interaction with filesystems. However, the way it was done opened up many security holes.

The functionality exploits the ability of the listener to issue operating system commands. The external procedures are supposed to issue the commands to the listener on a special IPC pipe named EXTPROC. The specification exists in the listener.ora file as

(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))

These external procedures operate by instructing the listener to issue these operating system commands on their behalf. Since the listener runs with the privilege of the operating system user oracle, the only limit to which commands can be executed by the external procedures is the limit on what the oracle account can do. This means the datafiles could potentially be deleted. Hackers can also use this feature to open up your server's filesystem and write malicious data, threatening data integrity.

External procedure service in listener is created by default. In most shops we have seen, this functionality is not used at all. But since the listener.ora file has it, the default listener is already listening for it, and stopping the listener, which is not an option, is the only way it can be deactivated.

There are two ways to handle this potential threat. If this is not used in your organization, remove it completely from the listener.ora file and restart the listener.

If the external procedures are to be used, remove the entry from listener.ora and place it in a separate listener. For instance, your original listener.ora file is probably similar to the following.

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =

        (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
      )
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = ANANDA)(PORT = 1521))
      )
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = IPC)(KEY=ANANDA))
      )
    )
)

SID_LIST_LISTENER =
(SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = d:\ora9)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = ANANDA)
      (ORACLE_HOME = d:\ora9)
      (SID_NAME = ANANDA)
    )
)

This can be changed to

LISTENER =
(DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =

        (ADDRESS = (PROTOCOL = TCP)(HOST = ANANDA)(PORT = 1521))
      )
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = IPC)(KEY=ANANDA))
      )
    )
)

LISTENER_EXTPROC =
(DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = IPC)(KEY=EXTPROC))
      )
    )
)

SID_LIST_LISTENER =
   (SID_LIST =
      (SID_DESC =
         (GLOBAL_DBNAME = ANANDA)
         (ORACLE_HOME = d:\ora9)
         (SID_NAME = ANANDA)
      )
   )

SID_LIST_LISTENER_EXTPROC =
   (SID_LIST =
      (SID_DESC =
         (SID_NAME = PLSExtProc)
         (ORACLE_HOME = d:\ora9)

(PROGRAM = extproc)
)
)

This will define two different listeners, LISTENER and LISTENER_EXTPROC, both of which are listening for regular database connections on port 1521, and then external procedures, respectively. The second listener could be down for most cases, and brought up only when needed. In case of a threat or suspicion of attack, the listener could be immediately brought down blocking hacking paths, but allowing other connections at the same time.

Avoid the default setup of the same listener monitoring database connections on ports as well as external procedures. Isolate external procedures to a separate listener that can be handled independently to control the risk.

Restricted Parameter Setting

One of the biggest problems in the listener parameters setting is the way the listener parameters can be easily changed by the SET command, such as

LSNTCTL> set rawmode on
LSNRCTL> services

This command will let the hacker know a whole lot of things helpful in launching an attack. For instance, with the non-RAW mode, the SERVICES command will produce the following output.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ANANDA)(PORT=1521)))
Services Summary...
Service "ANANDA" has 2 instance(s).
Instance "ANANDA", status UNKNOWN, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0
         LOCAL SERVER
Instance "ANANDA", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0 state:ready
         LOCAL SERVER

In RAW mode, the output of SERVICES command is

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ANANDA)(PORT=1521)))
Services Summary...
(SERVICE=(SERVICE_NAME=ANANDA)(INSTANCE=(INSTANCE_NAME=ANANDA)(NUM=1)(INSTANCE_STATUS=UNKNOWN)(HANDLER=(HANDLER_DISPLAY=DEDICATED SERVER)(HANDLER_INFO=LOCAL SERVER)(HANDLER_MAXLOAD=0)(HANDLER_LOAD=0)(ESTABLISHED=0)(REFUSED=0)(HANDLER_ID=6822DEBD0821-484B-8427-E204F5FE1EFD)(PRE=any)(HANDLER_NAME=DEDICATED)(SESSION=NS)(ADDRESS=(PROTOCOL=beq)(PROGRAM=oracle)(ENVS='ORACLE_HOME=d:\ora9,ORACLE_SID=ANANDA')(ARGV0=or

oracleANANDA)(ARGS='(LOCAL=NO)')))(NUMREL=1))(INSTANCE=(INSTANCE_NAME=
ANANDA)(NUM=2)(HANDLER=(HANDLER_DISPLAY=DEDICATED SERVER)(STA=ready)(HANDLER_INFO=LOCAL SERVER)(HANDLER_MAXLOAD=149)(HANDLER_LOAD=10)(ESTABLISHED=0)(REFUSED=0)(HANDLER_ID=E898681A4553-439B-8D5C-083DBDF02884)(PRE=any)(HANDLER_NAME=DEDICATED)
(SESSION=NS)(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oracleananda)(ARGS='(LOCAL=NO)')))(NUMREL=1)))

Note the detailed information produced, which can help the hacker is designing a strategy. Since one way we counter the threat is by displaying the minimum information, how do we prevent the hacker from issuing a SET command?

The answer is to set a parameter in listener.ora to ON, as follows:

ADMIN_RESTRICTIONS_LISTENER1 = ON

where LISTENER1 is the name of the listener. This can be changed to reflect the name of the listener to which this restriction is. While this parameter is set to ON, the SET command will fail. The only way to change a parameter is to change it in the listener.ora file, and then recycling the listener via a stop-start sequence or by the RELOAD command. A typical hacker will not be able to issue the RELOAD as easily as the SET command; therefore, this protection is adequate enough. Of course,

Note: Starting in 11gR2, the listener log is not activated by default. You have to turn on listener logging: logging_listener_name=on

Chapter 7 Oracle Network Security

This should definitely be in place if the listener does not have a password.

The apparent downside to this setting may seem to be the need to bounce the listener while setting innocuous settings such as log level or trace level. However, bouncing the listener is not as involved as bouncing the database, and this argument does not hold ground.

It is preferable to set the administration restrictions on the listener, in addition to the password setting.

Download your Oracle scripts now:

www.oracle-script.com

The definitive Oracle Script collection for every Oracle professional DBA