So much for 9i unbreakeable

[mike73]

Here we go guys so much for 9i unbreakeable, Oracle already fine bugs on this version

I hope this would help our members in here:

This security hole applies equally to Oracle 8, 8i, and 9i. It exploits a
vulnerability of ExtProc to execute arbitrary system commands without
authentication.

Oracle has no patch yet, only a workaround. They recommend you completely
remove ExtProc unless you specifically need it.
http://otn.oracle.com/deploy/securit...proc_alert.pdf

[marist89]

IMHO, Oracle was setting themselves up for failure when they proclaimed the software was unbreakable. Every piece of software known to man has a bug or security vulnerability in it somewhere.

[julian]

Here is the FIX information:

"There are several things that can be done to help mitigate the risk of such an attack. The first line of defense is, of course, with the use of a firewall. No one should be able to access the listener port of 1521 from the Internet. This not only helps mitigate the risk concerned with this problem but a slew of others, too. Moving to the Oracle database server itself, PLSExtproc functionality can be removed if not needed. To do this remove the relevant entries in tnsnames.ora and listener.ora. The PLS External Procedure service can have many different names depending upon the system and Oracle version installed. This could be icache_extproc, PLSExtproc or extproc. It is also suggested that extproc(.exe) be deleted, too, on the off chance that an attacker, replaces the entries in tnsnames.ora and listener.ora. If this functionality is required then it is possible to limit the machines that may access the listener. Whilst this is a trust mechanism based only on IP address it does help. The process is called "valid node checking" and requires a modification to the sqlnet.ora file found in the $ORACLE_HOME\network\admin directory. Add the entries tcp.validnode_checking = YES tcp.invited_nodes = (10.1.1.2, scylla) Replace 10.1.1.2 or Scylla in this example with the hosts that require access. Any host not listed here will still be able to make a TCP connection to the listener but the listener will simply terminate the connection. Invited nodes should be restricted to machines that require access. As another step towards help mitigating the risk, you could set the listener listening on a non-default port (i.e. not 1521). Whilst this is not a great solution, as anyone with a TCP port scanner has a highly likely chance of finding the listener, it still helps. Finally, on Windows NT/2000 the Oracle processes should not be running as local SYSTEM. It is suggested that a low privileged account be created and the Oracle processes run as this user. This account will need to be given the "Logon as a service" account privilege. Oracle was alerted to the theoretical vulnerability last summer and provided with working exploit code in October and are currently investigating the issue and working on a patch. NGSSoftware and Oracle have decided to release this advisory in the interim of the patch becoming available so Oracle customers may take steps to mitigate the risk that may be posed to their Oracle database servers. A check for this security hole has been added to the Oracle scan module of Typhon II, NGSSoftware's vulnerability assessment scanner, of which more information is available from the NGSSoftware website, http://www.nextgenss.com/. "

[kris109]

I agree with marist89 on this issue although I disagree with the way he goes about censoring this forum.

As long there is a username and a password for the database, it is breakable. This is an advertisement ploy by Larry, may be to boost 9i sales and the stock of his company.