--------------------------------------------------------------------------------
Vulnerability Details for Application
--------------------------------------------------------------------------------
COMPANY NAME:
PRINT DATE : 9/9/2004
TEST DATE : 9/9/2004 4:59:47 PM - 9/9/2004 5:03:02 PM
APPLICATION : Oracle8i Database (orcl) on 172.16.0.233, port 1521
--------------------------------------------------------------------------------
REPORT DESCRIPTION:
A security review has been run on a number of applications on your network. This review consisted of probing the application and comparing the results to a knowledge base of application security vulnerabilities.
This report displays a detailed list of all vulnerabilities found include a full analysis of the problem as well as a fix or work around. You should review each vulnerability and follow the fix instructions to close the holes.
This report is designed to provide a comprehensive description of each vulnerability found. You can also review a summary level overview of vulnerabilities by opening the Vulnerability Summary report.
REPORT SUMMARY:
------------------------------------------------------------
Vulnerabilities By Risk Level
------------------------------------------------------------
RiskLevel Vulnerability Count
------------------------------------------------------------
High 17
Medium 1
Low 6
Informational 0
------------------------------------------------------------
REPORT CONTENT:
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: ADMIN_RESTRICTIONS flag not set
> DESCRIPTION: The ADMIN_RESTRICTIONS flag has not been set.
> VERSION: Oracle8i and later
> CVE REFERENCE: CVE-2000-0818
> SUMMARY: If a password is not set on the listener service, an attack can read and write files on the operating system. To alleviate this issue, Oracle added a new parameter called ADMIN_RESTRICTIONS. The ADMIN_RESTRICTIONS flag disables the ability of the listener controller to set parameters, thereby not allowing remote users to set parameters. After setting this parameter, you must edit the listener parameters directly in the listener.ora file.
> OVERVIEW: If the listener password has not been set properly, an attacker can set any of the listener parameters. With this ability, an attacker could change the location or name of the trace or log file to create new files or append data to existing files. Once the log or trace file is changed, packets can be generated and sent to the listener which in turn will write them to the trace and log files.
This attack can be mounted by any remote users that can send packets to the IP address and port of the listener. It can not be mounted by an attacker outside your organization if a firewall is properly protecting the database.
This type of attack results in the following possible issues:
- corrupting files such as the database files
- creating files such as .rhost files allowing access directly to the operating system
For instance, a packet with a connect string formatted as below would write a `+ +` on a single line, enough to allow an attacker to rlogin to the operating system.
(CONNECT_DATA=((
+ +
To alleviate this issue, Oracle released a patch which added a flag to the listener.ora file. The new parameter, ADMIN_RESTRICTIONS_[listener_name], can be set in the listener.ora, the control file for the Oracle listener program. Replace the [listener_name] within the parameter name with the listener name for the specific listener the patch is being applied to. Setting ADMIN_RESTRICTIONS_[listener_name]=ON stops an attack by not allowing run-time modification of parameters in listener.ora. After setting this parameter, the listener program will refuse to accept SET commands that alter its parameters and attempting to issue a SET command will result in the generation of an error message. Thus, to change any one of the parameters in listener.ora, including ADMIN_RESTRICTIONS_[listener_name] itself, this file needs to be edited directly and the parameters need to be reloaded (e.g., LSNRCTL RELOAD) for the new changes to take effect. You can also stop and restart the listener program to reload these parameters. Operating system access to the protected Oracle account owner directories and files is required to edit listener.ora. Note that the Oracle account owner directories and files must be protected on the operating system by setting the access control permissions on them as recommended by Oracle Corporation in its user manuals.
ADMIN_RESTRICTIONS_[listener_name]=OFF is the default value when the listener program is installed in order to maintain current customer environments and backward compatibility. There is no change in the run-time behavior of the listener program or in the syntax of the SET commands in this mode of operation. You should set the listener password even if you have set this parameter.
> FIX/RECOMMENDATION: To set the parameter, add or modify the ADMIN_RESTRICTIONS_[listener name] parameter to the listener.ora file. Add the line ADMIN_RESTRICTIONS_[listener name] = ON (where [listener name] is the actual listener name in the listener.ora file) .
Then use the lsnrctl process to stop and start the Oracle listener or to reload the parameters. This will stop any value from being dynamically set.
You can download the patches for this vulnerability from Oracle`s Worldwide Support Services website http://metalink.oracle.com. Reference generic bug number 1361722 filed against the listener program.
--------------------------------------------------------------------------------
Vulnerability Detail: (ADMIN_RESTRICTION=off)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: BFILENAME buffer overflow (Verify version)
> DESCRIPTION: The database is vulnerable to a buffer overflow in the built-in function BFILENAME.
> VERSION: Oracle8, 8i, and 9i
> CVE REFERENCE: CAN-2003-05
> SUMMARY: A buffer overflow exists in the built-in function BFILENAME. This buffer overflow may allow an attacker to overwrite the stack and execute arbitrary code under the security context of the database server. BFILENAME is a built-in function and as such permissions to execute this function are granted to all database users.
> OVERVIEW: The Oracle database provides a built-in function called BFILENAME. BFILENAME is used to return a BFILE locator which is associated with a physical LOB binary file. The function accepts two parameters: DIRECTORY and FILENAME.
The buffer overflow occurs as Oracle attempts to copy the DIRECTORY value into a buffer on the stack. This buffer overflow does not result in the Oracle process crashing. However the buffer overflow does result in the saved return address being overwritten on the stack.
A user needs no privileges to execute this function. This security issue allows a non-privileged user to elevate his or her privileges to DBA.
> FIX/RECOMMENDATION: To fix this problem, you must download and apply the appropriate patch. Patches for the Oracle database server can be downloaded from Oracle Worldwide Support Services web site, Metalink (http://metalink.oracle.com). This patch is identified by the base bug number 2642117.
The issue is fixed in the 9.2.0.3 and 9.0.1.5 patchset. Patches are available for 9.2.0.2, 9.0.1.4, 8.1.7.4, and 8.0.6. For a detailed grid of the platform details, view the grid at http://otn.oracle.com/deploy/security/pdf/2003alert48.pdf.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Database Version=8.1.7.4.1) (OS Platform=Microsoft Windows) (VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: Database link buffer overflow (Verify version)
> DESCRIPTION: The database is vulnerable to a buffer overflow in the use of database links.
> VERSION: Oracle9i and earlier
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: A buffer overflow exists in the usage of database links. This buffer overflow may allow an attacker to overwrite the stack and execute arbitrary code under the security context of the database server. This vulnerability occurs when selecting from a database link which was
defined with a long connection string.
> OVERVIEW: A database link is a mechanism within an Oracle database to provide location transparency to read data from other databases. It is essentially a pointer to another database. The pointer is an entry in the data dictionary which includes the name of the remote server, a connection string, and possibly a username and password to authenticate to the remote system.
A database link is created using the following syntax:
CREATE DATABASE LINK [linkname] CONNECT TO [username] IDENTIFIED BY [password] USING `[connection string]`
If you designate a connection string longer than 1000 characters, the long value is saved into the data dictionary. The buffer overflow does not actually occur in this function. It is later when the database link is accessed that the buffer overflow occurs. The following command will cause the buffer overflow:
SELECT * FROM TEST@[linkname]
This buffer overflow does not result in the Oracle process crashing. However the buffer overflow does result in the saved return address being overwritten on the stack.
A user must have the CREATE DATABASE LINK privilege in order to execute this attack. By default the CONNECT role is granted this privilege, so an account such as SCOTT with a password of TIGER would allow any attacker to connect to the system, create a database link, and then select the database link.
> FIX/RECOMMENDATION: To fix this problem, you must download and apply the appropriate patch. Patches for the Oracle database server can be downloaded from Oracle Worldwide Support Services web site, Metalink (http://metalink.oracle.com). Patches are available for 9.2.0.2, 9.0.1.4, 8.1.7.4, and 8.0.6. The appropriate bug number for this patch can be found in the grid at http://otn.oracle.com/deploy/security/pdf/2003alert54.pdf.
As well, it is recommended that you do not use the built-in role CONNECT since it has excessive privileges such as CREATE DATABASE LINKS. Also, ensure that you have not left the SCOTT account on the system with the TIGER password.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Database Version=8.1.7.4.1) (OS Platform=Microsoft Windows) (VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: Default database password
> DESCRIPTION: A default database password has not been changed.
> VERSION: All versions of Oracle
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: Oracle is installed with a list of well-known usernames and passwords. If a default password has not been changed, an attacker can easily break into a database.
> OVERVIEW: There is a large number of well-known account/password combinations that can be used by an attacker to break into a database.
These account/password combinations are created from several sources:
1 - installed by default with the database
2 - installed when additional components or 3rd party applications are installed
3 - installed when running samples
After installing a database, you should immediately change any default usernames and passwords.
> FIX/RECOMMENDATION: A password can be changed by executing the command ALTER USER [username] IDENTIFIED BY [new password].
Any accounts you do not need, should be deleted. Accounts that you do need should be renamed if possible.
--------------------------------------------------------------------------------
Vulnerability Detail: (Username=dbsnmp) (Password=dbsnmp)
Vulnerability Detail: (Username=outln) (Password=outln)
Vulnerability Detail: (Username=sys) (Password=change_on_install)
Vulnerability Detail: (Username=system) (Password=manager)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: Easily-guessed password for internal account
> DESCRIPTION: The password for the internal user was guessed.
> VERSION: Oracle8i and earlier
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: If a strong password is not selected for the INTERNAL user, Oracle can be broken into by guessing the password. If an attacker can guess the password for the INTERNAL account, full control of the database can be gained by the attacker.
> OVERVIEW: The INTERNAL user is a privileged account that can be used to connect to the database to perform administrative tasks or to startup the database. Using the internal account connects you to the database as the user SYS with the privilege SYSDBA. This allows you unlimited access in the database.
The INTERNAL account is usually accessed by connecting to the operating system as a privileged user such as the owner of the Oracle software. The INTERNAL account can also be setup to use a password to allow remote access. This is done by setting the parameter REMOTE_PASSWORD_FILE to SHARED or EXCLUSIVE. To disable the ability to connect to the INTERNAL account using a password, set REMOTE_PASSWORD_FILE to NONE in the init.ora file.
The INTERNAL account no longer exists in version 9i of Oracle.
The Oracle documentation recommends setting REMOTE_LOGIN_PASSWORDFILE file initialization parameter to EXCLUSIVE immediately after creating the password file. For maximum security, you should not create a password file and should set the REMOTE_LOGIN_PASSWORDFILE parameter to NONE.
> FIX/RECOMMENDATION: The most secure way of preventing the internal account from being brute-forced is to remove the password file and to set the REMOTE_LOGIN_PASSWORDFILE parameter to NONE.
If you do use the internal account, set the password to have the following characteristics:
- the password uses a combination of numeric, alphabetic, and punctuation characters
- the password is at least 8 characters long
To set a strong password for the internal account, use the orapwd executable file to create a password file and then replace the current password file. The syntax for the orapwd is:
Usage: orapwd file=[fname] password=[password] entries=[users]
where
file - name of password file (mandatory),
password - password for SYS and INTERNAL (mandatory),
entries - maximum number of distinct DBAs and OPERs (optional),
There are no spaces around the equal-to (=) character.
--------------------------------------------------------------------------------
Vulnerability Detail: (Username=INTERNAL) (Password=oracle)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: Easily-guessed password for SYS as SYSDBA
> DESCRIPTION: The password to connect to the SYS user with the SYSDBA role was guessed.
> VERSION: All versions of Oracle
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: If a strong SYSDBA password is not selected for the SYS user, Oracle can be broken into by guessing the password.
> OVERVIEW: The SYS account is a privileged account that can be used to connect to the database to perform administrative tasks or to startup the database. This allows you full administrative rights on the database.
The use of the SYSDBA role is required to connect to the database before it is mounted, to startup an instance, and to perform other even more privileged administrative tasks, such as granting the SYSDBA role to other users.
The combination of the SYS account and the SYSDBA role is complicated and can lead to potential security holes in your database if misconfigured. This is because the SYS account can actually have two passwords associated with it.
- if you connect to the database as SYS without using the SYSDBA role, the SYS password hash is taken from in the SYS.USER$ table
- if you connect to the database as SYS using the SYSDBA role, the password hash is taken from the remote login password file (orapwd[SID] in Unix or pwd[SID].ora on Windows).
What password hash is stored in the remote login password file depends on several factors including
- the REMOTE_LOGIN_PASSWORDFILE parameter
- when and if the SYS password has been changed since after the remote login parameter file was created
If you set the REMOTE_LOGIN_PASSWORDFILE parameter to NONE, the second password hash is never used and authentication using the remote login password file can not be performed. Under this configuration, the only way to connect as SYS with the SYSDBA role is through an operating system user with the appropriate operating system privileges. This is the most secure configuration.
If you set the REMOTE_LOGIN_PASSWORDFILE parameter to EXCLUSIVE, changes made to the SYS password are changed in the remote login password file. This means that the password stored in SYS.USER$ will be synchronized with the hashes stored in the remote login password file. However this does not occur until after the first time the SYS password is changed subsequent to the remote login password file being generated. This means that if you set a weak password when generating the password file and never change the SYS password subsequent, the weak password will continue to exist and may allow an attacker to connect to SYS as SYSDBA. It is important to understand that you can have a weak password for connecting SYS as SYSDBA even if the database password stored in the SYS.USER$ table is strong.
If you set the REMOTE_LOGIN_PASSWORDFILE parameter to SHARED, changes made to the SYS password are never changed in the remote login password file. This means that whatever password you set when creating the remote login password file will remain as the password for connecting SYS as SYSDBA. Under this configuration there will always be two passwords for the SYS account.
The Oracle documentation recommends setting REMOTE_LOGIN_PASSWORDFILE file initialization parameter to EXCLUSIVE immediately after creating the password file. For maximum security, you should not create a password file and should set the REMOTE_LOGIN_PASSWORDFILE parameter to NONE.
> FIX/RECOMMENDATION: The most secure way of preventing the SYSDBA password for the SYS account from being brute-forced is to remove the password file and to set the REMOTE_LOGIN_PASSWORDFILE parameter to NONE.
If you do need to use the remote login password file, set the password to have the following characteristics:
- the password uses a combination of numeric, alphabetic, and punctuation characters
- the password is at least 8 characters long
To set a strong SYSDBA password for the SYS account, use the orapwd executable file to create a password file and then replace the current password file. The syntax for the orapwd is:
Usage: orapwd file=[fname] password=[password] entries=[users]
where
file - name of password file (mandatory),
password - password for SYS and INTERNAL (mandatory),
entries - maximum number of distinct DBAs and OPERs (optional),
There are no spaces around the equal-to (=) character.
--------------------------------------------------------------------------------
Vulnerability Detail: (Username=SYS) (Password=change_on_install)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: External procedure service found
> DESCRIPTION: At least one external procedure service is running.
> VERSION: All versions of Oracle
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: Oracle provides a method of calling functions outside the database by creating external procedure servers. This feature extends Oracle`s functionality greatly and is very useful. However, if access to send commands to these external procedure servers is not properly restricted, anonymous users can gain control of the operating system.
> OVERVIEW: External procedure are functions written outside of Oracle that can be called from within Oracle. External procedures allow functions in C or other languages to be called from PL/SQL. Several features of Oracle use the external procedure service to add functionality to the database.
From within the database, Oracle provides a special-purpose interface, the call specification (call spec), that enables users to call external procedures. From within the database, access to invoke the functions can be limited.
When an external procedure is invoked, the database alerts a network listener process, which in turn starts an external procedure agent, which by default is named extproc. Using the network connection established by the listener, the database passes to the external procedure agent the name of the DLL, the name of the external procedure, and any parameters passed in by the application. Then, the external procedure agent loads the DLL and runs the external procedure and passes back to the application any values returned by the external procedure.
The agent can reside on the same computer as the database server or on a remote computer with a listener. If not secured properly, an attacker can remotely cause the extproc to load an arbitrary shared library and execute a function in the shared library under the security context of the oracle owner.
> FIX/RECOMMENDATION: To alleviate the threat presented by exposing external procedure listeners to the network, you should perform one of the following tasks:
1. Configure the listener to not accept connections for the External Procedure server. This is accomplished by editing the entries in the listener.ora file. Within the listener.ora file, you will find the following entries.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = dev01win2ksvr)(PORT = 1521))
)
)
)
From the section above, remove the lines 4, 5, and 6 to cause the listener to stop accepting requests to spawn the extproc program.
2. Configure the listener used by the extproc to only accept connections from the database by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in the network/admin directory under the ORACLE_HOME directory or in the directory specified by the TNS_ADMIN environment variable or registry value.
tcp.validnode_checking = YES
tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)
tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)
The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.
Note that the tcp.invited_nodes parameter takes precedence over the
tcp.excluded_nodes parameter if both lists are present.
--------------------------------------------------------------------------------
Vulnerability Detail: (SID=iCache_extproc)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: EXTPROC buffer overflow (Verify version)
> DESCRIPTION: The EXTPROC executable is vulnerable to a buffer overflow.
> VERSION: Oracle9i Release 2 and earlier
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: A buffer overflow exists in the EXTPROC executable. This buffer overflow may allow an attacker to overwrite the stack and execute arbitrary code under the security context of the EXTPROC server.
> OVERVIEW: The EXTPROC (external procedure) service in Oracle allows a PL/SQL packages to load and call functions in operating system libraries or dynamic link libraries (DLLs). Whenever a call to load a function in an external library is made, the Oracle process contacts the Listener process. The Listener process in turn connects to the EXTPROC service and passes the name of the library and the requested function to it. There is absolutely no authentication involved in this process.
An attacker can pretend to be the Oracle service and request the Listener process to call functions in the external operating system libraries. Since there is no authentication the Listener will accept the call and run the EXTPROC utility, which in turn will call the actual function in the library.
The functionality in Oracle was changed in version 9.2.0.1.0 to prevent this by only allowing calls to the libraries available in $ORACLE_HOME\bin directory. As well, the EXTPROC still allows connections over TCP/IP but doesn`t service any remote calls. All these failed calls to EXTPROC get logged to a log file. There exists a buffer overflow with this logging functionality of EXTPROC. If the remote user tries to load a library with an overly long name, the EXTPROC rejects it and tries to log the library name. It`s during this process that the saved return address gets overwritten on the stack, allowing a malicious remote user to execute code of his choice.
Even if the EXTPROC limits the libraries that can be loaded to only the
$ORACLE_HOME\bin directory, there are several hundred shared libraries
in that directory, many of which may contain buffer overflows.
> FIX/RECOMMENDATION: To fix this problem, you must download and apply the appropriate patch. Patches for the Oracle database server can be downloaded from Oracle Worldwide Support Services web site, Metalink (http://metalink.oracle.com).
The issue is fixed in the 9.2.0.4 patchset. Patches are available for 9.2.0.2 and 9.2.0.3. For a complete matrix of patches available by platform, see http://otn.oracle.com/deploy/security/pdf/2003alert57.pdf.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Database Version=8.1.7.4.1) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: Listener password not enabled
> DESCRIPTION: The password feature for the listener service was not enabled.
> VERSION: All versions of Oracle
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: A strong password must be set on the listener service to prevent remote users from guessing the password. If the password feature is not enabled, an attacker can use the listener service to write files on the operating system, possibly gaining access as the account that owns oracle.
> OVERVIEW: The password feature has not been enabled for the listener. If you do not set a listener password, an attacker can easily gain control over the listener service and can
- shutdown the listener or
- perform other administrative actions on the listener
This attack can be mounted by any remote users that can send packets to the IP address and port of the listener. It can not be mounted by an attacker outside your organization if a firewall is properly protecting the database.
This is a dangerous vulnerability since many database administrators are unaware that the listener service accepts commands from remote sources. This allows anyone on the network to attempt to break into the listener.
Not setting a listener password is one of the most common misconfigurations found on Oracle databases. As of Oracle8 and later, no listener password is set during the installation process. In Oracle7, the password is set to `oracle` by default. It is very important that the database administrator specifically set the password immediately after installing the database.
Not setting a listener password allows an attacker to take actions such as:
- creating .rhost files or adding commands to the autoexec.bat file
- corrupting the oracle database files
If you do not set a password on the listener, an attacker can gain control of the listener and use the actions listed above to gain access to the operating system as the owner of the oracle software.
NOTE: A common misconception is that not setting a password only results in a DoS attack by shutting down the listener service. In reality, not setting a password will allow anyone that can send a TCP/IP packet to the listener to be able to write arbitrary files on the operating system under the privileges of the oracle user.
The listener:
- is a server-side program that manages connecting clients to the database.
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
The listener typically runs under the following privileges:
- Using the oracle software owner account on UNIX
- Using the LocalSystem account on Windows
Because the listener has such a high level of privileges, any actions this process can take should be restricted.
> FIX/RECOMMENDATION: To set a password on the listener service, you can use one of two methods. The preferred method is to use the Listener Controller Utility, lsnrctl. Below is an example of how to set the password using the listener controller.
From an operating system prompt, type the following command.
$ORACLE_HOME/bin/lsnrctl
At the lsnrctl prompt, issue the following commands.
LSNRCTL]change_password
Old password:
New password:
Reenter new password:
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC0)))
Password changed for LISTENER
The command completed successfully.
At the lsnrctl prompt, issue the command set password.
LSNRCTL]set password xxxxxx
The command completed successfully
At the lsnrctl prompt, issue the following command.
LSNRCTL]save_config
The command completed successfully
There are problems with the listener controller that may cause this process to fail. If you are unable to set the password through the listener controller, you can set the password in the listener.ora file found in the ORACLE_HOME/network/admin directory. The format of the setting is:
PASSWORDS_listener_name=(password[,password])
The optional parameter allows one or more passwords. If this parameter is specified with one or more passwords, then the use of one of these passwords is required to perform administrative tasks on the listener using the Listener Control Utility.
For example:
PASSWORDS_LISTENER=(dfg4fE3, fRf3df)
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Password Set=OFF)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: NSPTCN buffer overflow (Verify version)
> DESCRIPTION: This version of the database is known to be vulnerable to a buffer overflow in the NSPTCN packet by sending a command of several thousand bytes.
> VERSION: All versions of Oracle8i and earlier
> CVE REFERENCE: CVE-2001-0499
> SUMMARY: A buffer overflow attack exists that allows an anonymous user to execute arbitrary commands by sending a long argument in the connection string.
> OVERVIEW: A buffer overflow exists that allows an anonymous attacker to execute arbitrary shell commands under the security context of the listener service. In the first packet sent to an Oracle listener, called the NSPTCN packet, a connection string is sent which describes the database to which to connect and includes optional commands. When an attacker creates a connection string of greater than several thousand bytes, the structured exception handler mechanism can be manipulated to run opcodes contained in the connection string.
This attack leaves the listener in a corrupt state. In order to restart the listener, the listener must first be stopped and then started again.
This attack can be mounted by any remote users that can send packets to the IP address and port of the listener. It can not be mounted by an attacker outside your organization if a firewall is properly protecting the database.
The listener:
- is a server-side program that manages connecting clients to the database
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
The listener typically runs under the following privileges:
- Using the oracle software owner account on UNIX
- Using the LocalSystem account on Windows
Because the listener has such a high level of privileges, any actions this process can take should be restricted.
> FIX/RECOMMENDATION: Patches exist on most platforms for versions 8.1.7.1 (patch number 1859604), 8.1.6.3 (patch number 1859654), and 8.0.6.3 (patch number 1864109).
For a detailed grid of the specific patch numbers and the platform details, view the grid at ftp://oracle-ftp.oracle.com/server/patchsets/Listener_Security_Patch/README_FIRST.html. You can download the patches from ftp://oracle-ftp.oracle.com/server/patchsets.
This problem can also be solved by upgrading the listener to Oracle9i. Installing or upgrading only need to be done on the listener, not necessarily on the database.
Not all versions of Oracle have been patched. If your listener is not a currently supported version, there will not be a patch available. In this case, you should take actions to restrict who can access the database. One method to limit access is by restricting the IP addresses that are allowed to connect to the listener. This can be controlled by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.
tcp.validnode_checking = YES
tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)
tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)
The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.
Note that the tcp.invited_nodes parameter takes precedence over the tcp.excluded_nodes parameter if both lists are present.
This solution is still not perfect since you can not include a list of all the addresses that should not access your database, and maintaining the list of allowed users would involve a significant amount of administrative work. Also note that spoofing IP addresses, which is very possible although does require some hacking skills, makes this security feature unreliable. If you must use this solution, it is recommended that your database be behind a firewall.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Version=8.1.7.0.0) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: Password for database user same as username
> DESCRIPTION: A password for a database user was the same as the username.
> VERSION: All versions of Oracle
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: If the username is the same as the password, an attacker can easily break into the account.
> OVERVIEW: Strong passwords should be used for all Oracle users. If you allow accounts to have passwords that are the same as the username, an attacker can easily guess the password and break into a database.
> FIX/RECOMMENDATION: Make sure the following validations are performed for all passwords:
- all passwords use a combination of numeric, alphabetic, and punctuation characters
- all passwords are at least 6 to 8 characters long
To change a password, issue the following command through an application such as SQL*Plus:
alter user [USERNAME] identified by [NEWPASSWORD]
--------------------------------------------------------------------------------
Vulnerability Detail: (Username=MIKE) (Password=MIKE)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: SERVICE_NAME buffer overflow (Verify version)
> DESCRIPTION: This version of the database is known to be vulnerable to a buffer overflow caused by sending a SERVICE_NAME parameter of several thousand bytes in a connect string.
> VERSION: Oracle7, Oracle8, Oracle8i, and Oracle9i on Windows/VM
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: A buffer overflow attack exists in the Oracle listener service that allows an anonymous user to execute arbitrary commands by sending a long SERVICE_NAME in the connection string.
> OVERVIEW: A buffer overflow exists that allows an anonymous attacker to execute arbitrary shell commands under the security context of the listener service. In the first packet sent to an Oracle listener, a connection string is sent which describes the database to which to connect and includes optional commands. Within the connection string is a field called SERVICE_NAME. When the SERVICE_NAME is 8000 bytes or longer, a buffer overflow occurs in the listener service.
Below is an example of a connection string:
DESCRIPTION=(ADDRESS= (PROTOCOL=TCP)(HOST=192.168.1.100)(PORT=1521))(CONNECT_DATA= (SERVICE_NAME=appsecinc.com)(CID=(PROGRAM=C:\Oracle\SQLPLUSW.EXE) )
When the long SERVICE_NAME is sent to the listener, the following entry will appear in the listener log file:
12-JUN-2002 19:02:24 * 12502
TNS-12502: TNS:listener received no CONNECT_DATA from client
When forming the error message written to the listener log file, the stack is overwritten causing the buffer overflow.
This attack does not crash the listener. This attack can be mounted by any remote users that can send packets to the IP address and port of the listener.
The listener:
- is a server-side program that manages connecting clients to the database
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
The listener typically runs under the following privileges:
- Using the oracle software owner account on UNIX
- Using the LocalSystem account on Windows
Because the listener has such a high level of privileges, any actions this process can take should be restricted.
> FIX/RECOMMENDATION: This vulnerability occurs for all versions of Oracle running Windows prior to Oracle9i release 2. A patch is available for Oracle 9.0.1.3 (patch number 2367681) on Windows. No patch is yet available for older versions of the listener.
This problem can also be solved by upgrading the listener to Oracle9i Release 2. Installing or upgrading only needs to be done on the listener, not necessarily on the database.
Not all versions of Oracle have been patched. If a patch is not available for your version of the listener, you should take actions to restrict who can access the listener. One method of limiting access is to restrict the IP addresses that are allowed to connect to the listener. This can be controlled by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.
tcp.validnode_checking = YES
tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)
tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)
The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.
Note that the tcp.invited_nodes parameter takes precedence over the tcp.excluded_nodes parameter if both lists are present.
This solution is still not perfect since you can not include a list of all the addresses that should not access your database, and maintaining the list of allowed users would involve a significant amount of administrative work. Also note that spoofing IP addresses, which is very possible although does require some hacking skills, makes this security feature unreliable. If you must use this solution, it is recommended that your database be behind a firewall.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Version=8.1.7.0.0) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: SSL vulnerabilities (Verify version)
> DESCRIPTION: This version of Oracle is vulnerable to several SSL attacks.
> VERSION: Oracle9i and 8i
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: A number of vulnerabilities in the SSL libraries used by Oracle contain security vulnerabilities. These vulnerabilities range from leaking information to allowing execution of malicious code.
> OVERVIEW: Secure Sockets Layer (SSL) is an industry standard protocol used to communicate securely over a network. A series of vulnerabilities exist in the SSL libraries used by the Oracle database. Oracle uses the OpenSSL libraries (www.openssl.org) in its implementation of network encryption. These vulnerabilities result in several security concerns, ranging from information (including key) leakage to full exploitation of the system running the SSL libraries.
The vulnerabilities relate to the ASN.1 parsing the SSL libraries perform when handling X.509 certificates. For full details on the vulnerabilities, reference the CERT advisory at http://www.cert.org/advisories/CA-2003-26.html.
The Oracle database server uses these libraries and as such is vulnerable to these security risks.
> FIX/RECOMMENDATION: You must apply the patch for the database. Patches for the Oracle database server can be downloaded from Oracle Worldwide Support Services web site, Metalink (http://metalink.oracle.com).
Patches are available for the following versions of Oracle:
9.2.0.4, 9.2.0.3, 9.0.1.4, 8.1.7.4
For the detailed list of the specific patches to apply, see the Metalink Document ID 249034.1 located at http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT#x26;p_id=249034.1.
If you are running an earlier patchset, you must upgrade the patch set. Later patchset are not vulnerable. As well, if you are running the Oracle HTTP Server, you must apply that patch separately and in addition to the RDBMS patch. All versions of the Oracle HTTP Server can be fixed by applying patch number 3169446.
--------------------------------------------------------------------------------
Vulnerability Detail: (Database Version=8.1.7.4.1) (OS Platform=Microsoft Windows) (VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)
--------------------------------------------------------------------------------
> RISK LEVEL: High
> CHECK NAME: Username buffer overflow (Verify version)
> DESCRIPTION: The database is vulnerable to a buffer overflow in the authentication mechanism resulting from sending a long username.
> VERSION: Oracle8, 8i, and 9i
> CVE REFERENCE: CAN-2003-05
> SUMMARY: A buffer overflow exists in the authentication mechanism of Oracle. This buffer overflow may allow an attacker to overwrite the stack and execute arbitrary code under the security context of the database server. This vulnerability occurs when a very long username is passed during authentication to the database.
> OVERVIEW: During the authentication process of connecting to an Oracle database, a username and password are sent to the server. Typically client applications, particularly those from Oracle, are designed to limit the length of the username passed in for authentication. However, if a username of 1150 characters or greater is passed to the authentication mechanism, a buffer overflow occurs. This overflow occurs before authentication occurs, so an unauthenticated attacker could use this buffer overflow to gain full control of a database.
This buffer overflow does not result in the Oracle process crashing. However the buffer overflow does result in the saved return address being overwritten on the stack.
Although most applications truncate the username, one program included in the Oracle utilities is known to allow long usernames. The loadpsp utility found in the $ORACLE_HOME/bin directory can be called as follows:
C:\oracle\bin] loadpsp -name -user XXX[1150 additional characters]/test@iasdb test
> FIX/RECOMMENDATION: To fix this problem, you must download and apply the appropriate patch. Patches for the Oracle database server can be downloaded from Oracle Worldwide Support Services web site, Metalink (http://metalink.oracle.com). This patch is identified by the base bug number 2620726.
The issue is fixed in the 9.2.0.3 and 9.0.1.5 patchset. Patches are available for 9.2.0.2, 9.0.1.4, 8.1.7.4, and 8.0.6. For a detailed grid of the platform details, view the grid at http://otn.oracle.com/deploy/security/pdf/2003alert51.pdf.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Database Version=8.1.7.4.1) (OS Platform=Microsoft Windows) (VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)
--------------------------------------------------------------------------------
> RISK LEVEL: Medium
> CHECK NAME: Listener format string buffer overflow (Verify version)
> DESCRIPTION: The listener controller is susceptible to a format string buffer overflow.
> VERSION: Oracle9i and earlier
> CVE REFERENCE: CVE-NO-MATCH
> SUMMARY: The listener controller utility loads and parses the file listener.ora when starting up an instance of the listener. The listener controller process does not properly handle format strings placed in the file and if an attacker places a maliciously-crafted format string in the file, the listener controller will overwrite the stack and possible execute arbitrary code.
> OVERVIEW: The listener process is the service that accepts and manages connections from the client to the Oracle database. When the listener service is started, the listener controller utility reads the entries in the file listener.ora to determine how to load the listener. Within the listener.ora file are entries that indicate which ports to listener on, what protocols to use, etc. If a maliciously-crafted entry contains a format string, the listener controller fails to handle the entry and ends up overwriting areas of memory and crashing. If crafted correctly, a malicious entry in the listener.ora could cause the listener controller to overwrite the stack pointer and execute arbitrary code. This would only occur when the Oracle database administrator restarted the listener.
This is a vulnerability only if an attacker can make changes to the listener.ora file. By default, the listener service allows a remote user to do so. To prevent this, you should set a password on the listener and set the parameter ADMIN_RESTRICTIONS_[listener name] to true.
The listener:
- is a server-side program that manages connecting clients to the database.
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
The listener typically runs under the following privileges:
- Using the oracle software owner account on UNIX
- Using the LocalSystem account on Windows
Because the listener has such a high level of privileges, any actions this process can take should be restricted.
> FIX/RECOMMENDATION: This vulnerability affects all supported platforms.
Following versions of Oracle database are affected:
Oracle9i Release 2 (9.2.0.1)
Orace9i Release 1 (9.0.1.3 and below)
Oracle8i (8.1.7.4 and below)
Oracle7, Release 7.3.4
Oracle9i Release 2 versions 9.2.0.2 and above are not affected.
Oracle9i Release 1 versions 9.0.1.4 and above are not affected
There are several fixes for this vulnerability.
It is highly recommended that you set a password on the listener process. This will prevent someone without the password from setting any value through the listener service.
A patch is available for most of the supported platforms and versions of Oracle database at http://metalink.oracle.com. Search for the patch number 2395416.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Version=8.1.7.0.0) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: Low
> CHECK NAME: MTDS DoS (Verify version)
> DESCRIPTION: This version of the database is known to be vulnerable to a denial of service attack by sending an invalid value in the Maximum Transport Data Size field of the connection packet to the listener.
> VERSION: Oracle8i and Oracle8
> CVE REFERENCE: CVE-2001-0517
> SUMMARY: A denial of service vulnerability was discovered in Oracle8i and Oracle8. A listener can be crashed by sending a connection packet with an invalid value in the Maximum Transport Data Size field in a connection packet.
> OVERVIEW: A denial of service was found in Oracle8i and Oracle8 that exists that allows an attacker to cause the listener to crash.
The first packet sent to an Oracle listener before connecting to the database, called the NSPTCN packet, has a header. Within the header is a value that indicates the Maximum Transport Data Size (MTDS). A denial of service occurs when an attacker sets the MTDS to an invalid value such as 0 or 0xFFFF.
Because this packet is sent before authentication is performed, this attack can be mounted by anyone that can send a packet to the listener. If the listener is behind a firewall, the listener is protected from attacks through the firewall. Attacks can still be mounted by users that can get through the firewall or are on the internal network.
The listener:
- is a server-side program that manages connecting clients to the database.
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
> FIX/RECOMMENDATION: Patches exist on most platforms for versions 8.1.7.1 (patch number 1859604), 8.1.6.3 (patch number 1859654), and 8.0.6.3 (patch number 1864109).
A detailed list of the specific patch numbers for each platform can be viewed at ftp://oracle-ftp.oracle.com/server/patchsets/Listener_Security_Patch/README_FIRST.html. You can download the patches from ftp://oracle-ftp.oracle.com/server/patchsets.
This problem can also be solved by upgrading the listener to Oracle9i. Installing or upgrading only need to be done on the listener, not necessarily on the database.
Not all versions of Oracle have been patched. If your listener is not a currently supported version, there will not be a patch available. In this case, you should take actions to restrict who can access the database. One method to limit access is by restricting the IP addresses that are allowed to connect to the listener. This can be controlled by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.
tcp.validnode_checking = YES
tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)
tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)
The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.
Note that the tcp.invited_nodes parameter takes precedence over the tcp.excluded_nodes parameter if both lists are present.
This solution is not perfect since you can not include a list of all the addresses that should not access your database, and maintaining the list of allowed users would involve a significant amount of administrative work. Also note that spoofing IP addresses, which is very possible although does require some hacking skills, makes this security feature unreliable. If you must use this solution, it is recommended that your database be behind a firewall.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Version=8.1.7.0.0) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: Low
> CHECK NAME: NSPTCN data offset DoS (Verify version)
> DESCRIPTION: This version of the database is known to be vulnerable to a denial of service attack. The listener may crash when an invalid offset-to-data value is set in the NSPTCN packet.
> VERSION: All versions of Oracle8i and earlier
> CVE REFERENCE: CVE-2001-498,CVE-2001-0515
> SUMMARY: A denial of service attack was discovered in Oracle8i and Oracle8 that allows an anonymous user to crash the listener service by sending an invalid value for the offset-to-data field in an NSPTCN packet.
> OVERVIEW: A denial of service was found in Oracle8i and Oracle8 that causes the listener to read invalid memory resulting in crashing the listener.
In the first packet sent to an Oracle listener, called the NSPTCN packet, a connection string is sent which describes the database to which to connect. Within the header of this packet is a value that indicates the offset within the packet to where the connection string starts. A denial of service occurs when an attacker sets the offset to a value beyond the end of the packet.
Because this packet is sent before authentication is performed, this attack can be mounted by anyone that can send a packet to the listener. If the listener is behind a firewall, the listener is protected from attacks through the firewall. Attacks can still be mounted by users that can get through the firewall or are on the internal network.
The listener:
- is a server-side program that manages connecting clients to the database.
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
> FIX/RECOMMENDATION: Patches exist on most platforms for versions 8.1.7.1 (patch number 1859604), 8.1.6.3 (patch number 1859654), and 8.0.6.3 (patch number 1864109).
For a detailed grid of the specific patch numbers and the platform details, view the grid at ftp://oracle-ftp.oracle.com/server/patchsets/Listener_Security_Patch/README_FIRST.html. You can download the patches from ftp://oracle-ftp.oracle.com/server/patchsets.
This problem can also be solved by upgrading the listener to Oracle9i. Installing or upgrading only need to be done on the listener, not necessarily on the database.
Not all versions of Oracle have been patched. If your listener is not a currently supported version, there will not be a patch available. In this case, you should take actions to restrict who can access the database. One method to limit access is by restricting the IP addresses that are allowed to connect to the listener. This can be controlled by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.
tcp.validnode_checking = YES
tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)
tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)
The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.
Note that the tcp.invited_nodes parameter takes precedence over the tcp.excluded_nodes parameter if both lists are present.
This solution is still not perfect since you can not include a list of all the addresses that should not access your database, and maintaining the list of allowed users would involve a significant amount of administrative work. Also note that spoofing IP addresses, which is very possible although does require some hacking skills, makes this security feature unreliable. If you must use this solution, it is recommended that your database be behind a firewall.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Version=8.1.7.0.0) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: Low
> CHECK NAME: NSPTCN long command DoS (Verify version)
> DESCRIPTION: This version of the database is known to be vulnerable to a DoS attack in the NSPTCN packet by sending a command of several thousand bytes.
> VERSION: All versions of Oracle8i and earlier
> CVE REFERENCE: CVE-2001-0499
> SUMMARY: A denial of service attack exists that allows an anonymous user to crash the listener by sending a long command in the connection string. While causing the database to fail is a nuisance, more sophisticated hackers can use a denial of service attack to bring down a server, allowing the attacker to spoof the database.
> OVERVIEW: A buffer overflow exists that allows an anonymous attacker to execute arbitrary shell commands under the security context of the listener service. In the first packet sent to an Oracle listener, called the NSPTCN packet, a connection string is sent which describes the database to which to connect and includes optional commands. When an attacker creates a connection string of greater than several thousand bytes, the structured exception handler mechanism can be manipulated to run opcodes contained in the connection string.
This attack leaves the listener in a corrupt state. In order to restart the listener, the listener must first be stopped and then started again.
This attack can be mounted by any remote users that can send packets to the IP address and port of the listener. It can not be mounted by an attacker outside your organization if a firewall is properly protecting the database.
The listener:
- is a server-side program that manages connecting clients to the database
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
The listener typically runs under the following privileges:
- Using the oracle software owner account on UNIX
- Using the LocalSystem account on Windows
Because the listener has such a high level of privileges, any actions this process can take should be restricted.
> FIX/RECOMMENDATION: Patches exist on most platforms for versions 8.1.7.1 (patch number 1859604), 8.1.6.3 (patch number 1859654), and 8.0.6.3 (patch number 1864109).
For a detailed grid of the specific patch numbers and the platform details, view the grid at ftp://oracle-ftp.oracle.com/server/patchsets/Listener_Security_Patch/README_FIRST.html. You can download the patches from ftp://oracle-ftp.oracle.com/server/patchsets.
This problem can also be solved by upgrading the listener to Oracle9i. Installing or upgrading only need to be done on the listener, not necessarily on the database.
Not all versions of Oracle have been patched. If your listener is not a currently supported version, there will not be a patch available. In this case, you should take actions to restrict who can access the database. One method to limit access is by restricting the IP addresses that are allowed to connect to the listener. This can be controlled by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.
tcp.validnode_checking = YES
tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)
tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)
The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.
Note that the tcp.invited_nodes parameter takes precedence over the tcp.excluded_nodes parameter if both lists are present.
This solution is still not perfect since you can not include a list of all the addresses that should not access your database, and maintaining the list of allowed users would involve a significant amount of administrative work. Also note that spoofing IP addresses, which is very possible although does require some hacking skills, makes this security feature unreliable. If you must use this solution, it is recommended that your database be behind a firewall.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Version=8.1.7.0.0) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: Low
> CHECK NAME: Redirection DoS (Verify version)
> DESCRIPTION: The database performs redirections and may be vulnerable to a DoS attack by starting but not finishing the logon sequence multiple times.
> VERSION: All versions of Oracle that redirect connection. This includes Oracle on Windows and Oracle on Unix configured as multi-threaded.
> CVE REFERENCE: CVE-2001-0513
> SUMMARY: A denial of service attack exists by performing the beginning but not completing the logon sequence multiple times on a server that redirects connections to a new port. This attack allows an anonymous attacker to bring down the database and possible cause the operating system to crash.
> OVERVIEW: A denial of service exists for any Oracle database that redirects connection attempts to a second port.
A denial of service can occur when an attacker repeatedly requests for the listener to create a new database thread and does not connect to the port on which the new thread is waiting. Each thread consumes several dozen kilobytes of memory. If the attacker is able to create enough connections, the database will run out of memory.
This attack can be mounted by any remote users that can send packets to the IP address and port of the listener. It can not be mounted by an attacker outside your organization if a firewall is properly protecting the database.
The listener:
- is a server-side program that manages connecting clients to the database.
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
> FIX/RECOMMENDATION: There are several steps you can take to reduce your susceptibility to this DoS attack.
1 - Setup a firewall to prevent anonymous users from connecting to the listener service. This prevention method makes external attacks more difficult, but does nothing to prevent attacks by authorized users.
2 - Configure the listener to limit which clients can connect to the listener by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.
tcp.validnode_checking = YES
tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)
tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)
The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.
Note that the tcp.invited_nodes parameter takes precedence over the tcp.excluded_nodes parameter if both lists are present.
This solution is still not perfect since you can not include a list of all the addresses that should not access your database, and maintaining the list of allowed users would involve a significant amount of administrative work. Also note that spoofing IP addresses, which is very possible although does require some hacking skills, makes this security feature unreliable.
3 - Configure the database to not redirect connections. Unfortunately this security measure is not recommended because it reduces the scalability of Oracle by using more resources per connection.
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Version=8.1.7.0.0) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: Low
> CHECK NAME: Requestor version DoS (Verify version)
> DESCRIPTION: This version of the database is known to be vulnerable to a denial of service attack by sending an invalid Requestor Version to the listener.
> VERSION: Oracle8i and Oracle8
> CVE REFERENCE: CVE-2001-0516
> SUMMARY: A denial of service attack exists that allows an anonymous user to crash the listener service by sending an invalid Requestor Version in the header.
> OVERVIEW: A denial of service exists that allows an anonymous attacker to cause the listener to crash.
The first packet sent to an Oracle listener, called the NSPTCN packet, has a header. Within the header is a value that indicates the Requestor Version. A denial of service occurs when an attacker sets the Requestor Version to an invalid value which does not comply with other fields in the message.
The listener:
- is a server-side program that manages connecting clients to the database.
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
> FIX/RECOMMENDATION: Patches exist on most platforms for versions 8.1.7.1 (patch number 1859604), 8.1.6.3 (patch number 1859654), and 8.0.6.3 (patch number 1864109).
For a detailed grid of the specific patch numbers and the platform details, view the grid at ftp://oracle-ftp.oracle.com/server/patchsets/Listener_Security_Patch/README_FIRST.html. You can download the patches from ftp://oracle-ftp.oracle.com/server/patchsets.
This problem can also be solved by upgrading the listener to Oracle9i. Installing or upgrading only need to be done on the listener, not necessarily on the database.
Not all versions of Oracle have been patched. If your listener is not a currently supported version, there will not be a patch available. In this case, you should take actions to restrict who can access the database. One method to limit access is by restricting the IP addresses that are allowed to connect to the listener. This can be controlled by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.
tcp.validnode_checking = YES
tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)
tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)
The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.
Note that the tcp.invited_nodes parameter takes precedence over the tcp.excluded_nodes parameter if both lists are present.
This solution is still not perfect since you can not include a list of all the addresses that should not access your database, and maintaining the list of allowed users would involve a significant amount of administrative work. Also note that spoofing IP addresses, which is very possible although does require some hacking skills, makes this security feature unreliable. If you must use this solution, it is recommended that your database be behind a firewall.
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Listener Version=8.1.7.0.0) (OS Platform=Microsoft Windows)
--------------------------------------------------------------------------------
> RISK LEVEL: Low
> CHECK NAME: SERVICE_CURLOAD DoS (Verify version)
> DESCRIPTION: This version of Oracle is known to crash when the SERVICE_CURLOAD command is sent to the listener.
> VERSION: Oracle8i and Oracle 9i
> CVE REFERENCE: CAN-2002-1118
> SUMMARY: The listener service stops responding after the SERVICE_CURLOAD command is sent to the listener service. This issue allows an unauthenticated user to prevent access to the database.
> OVERVIEW: A denial of service attack exists that allows an anonymous attacker to crash the listener service, thus preventing access to the database. If a would-be hacker sends a maliciously crafted packet to an Oracle listener service, the listener service will crash. This leads to denial of access to the database.
The problem occurs when a command string such as `(CONNECT_DATA=(COMMAND=SERVICE_CURLOAD))` is sent to the listener service. The command executes successfully. However, after the command executes, the listener crashes and does not respond to further commands.
This attack can be mounted by any remote users that can send packets to the IP address and port of the listener.
The listener:
- is a server-side program that manages connecting clients to the database
- handles the connection request from a client to a database
- first accepts the connection and then negotiates with the database to setup a channel between the two ends
- returns the connection information to the client allowing the client and database to establish a connection
The listener typically runs under the following privileges:
- Using the oracle software owner account on UNIX
- Using the LocalSystem account on Windows
> FIX/RECOMMENDATION: This vulnerability affects all supported platforms.
Following versions of Oracle database are affected:
Oracle9i Release 2 (9.2.0.1, 9.2.0.2)
Oracle9i Release 1 (9.0.1.4 and below)
Oracle8i (8.1.x - all releases)
Oracle8 (8.0.x - all releases)
Oracle7 Release 7.3.x
Oracle9i Release 2 versions 9.2.0.3 and above are not affected.
You should apply the security patch from Oracle. Patches exist for most platforms and versions at http://metalink.oracle.com. Search for patch number 2540219.
For a detailed grid of the specific patch numbers and the platform details, view the grid at http://otn.oracle.com/deploy/security/pdf/2002alert42rev1.pdf
If a vulnerability on your server was discovered for this check and the details of the vulnerability include `(VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)`, you should manually verify the patch is installed or run an audit which will precisely confirm the patch level.
--------------------------------------------------------------------------------
Vulnerability Detail: (Database Version=8.1.7.4.1) (OS Platform=Microsoft Windows) (VERSION IS VULNERABLE=COULD NOT ACCURATELY DETERMINE IF PATCH IS APPLIED-RUN AN AUDIT TO VERIFY IF EXACT PATCH IS INSTALLED)
--------------------------------------------------------------------------------
No Vulnerability Found for Informational Risk Level.
Powered by Application Security, Inc.