 |
|
Oracle Tips by Burleson |
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
|
|