RE: Oracle Security Alert for CVE-2012-1675 - 10g extended support

The patch will not be delivered to 10.2 customers with no extended support agreement. Unless you have an extended support agreement, you cannot use the TCP solution.

Follow the instructions for using the IPC solution where no patch is necessary.

Using Class of Secure Transport (COST) to Restrict Instance Registration (Doc ID 1453883.1)

Start here:

Setting a COST restriction using the IPC protocol to limit registration to local instances.

From: Carol Dacko [mailto:dackoc_at_gmail.com] Sent: Thursday, May 03, 2012 1:36 PM
To: bdbafh_at_gmail.com
Cc: Lu.Jiang_at_umassmed.edu; oracle Freelists Subject: Re: Oracle Security Alert for CVE-2012-1675 - 10g extended support

All,

THE FOLLOWING IS NOT APPLICABLE FOR RAC - only single instance Oracle databases

This is what we are doing to protect our 10g and 11g versions of the listener before we can apply the workaround described in the CVE_2012_1675.

Directions

1) Save listener.ora file to listener.ora.OLD1
2) Edit the listener.ora file by putting in DYNAMIC_REGISTRATION_<NAME_OF_LISTENER> = OFF
3) Ensure that all the databases on that server and included in the listener.ora file. Otherwise, folks will be unable to connect to that database
4)   LSNRCTL> show dynamic_registration

                        Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=<whatever port number you are using))
                        LISTENER parameter "dynamic_registration" set to ON
                        The command completed successfully

    LSNRCTL> reload <NAME_OF_LISTENER>

                        Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=<our instance name>))
                        The command completed successfully

     LSNRCTL> show dynamic_registration

                        Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=<whatever port number you are using))
                        LISTENER parameter "dynamic_registration" set to OFF
                        The command completed successfully

     LSNRCTL> exit

Setting this parameter was suggested by a top Security person in this article and was confirmed by Oracle Support that this would work:

https://www.computerworld.com/s/article/9226674/Researcher_misinterprets_Oracle_advisory_discloses_unpatched_database_vulnerability Again, this only applies to Single Instance Oracle databases. Here are some work arounds suggested by a different security person but not confirmed by Oracle Support because we do not have RAC here. Please confirm with Oracle Support before applying any other methods than those described in CVE_2012_1675:

Possible workarounds

There are many possible workarounds. The easier one is to set the

following parameter in the listener.ora configuration file:

dynamic_registration = off.

But, sometimes, you don't want to apply this workaround. In example, if

you have an Oracle RAC cluster, all the cluster's instances must be

registered in both TNS Listeners so, this workaround is not suitable for

Oracle RAC clusters. To apply this workaround with Oracle RAC

environments one needs to implement load balancing at the client side,

changing all the client's tnsnames.ora configuration file to add the

complete list of Oracle RAC nodes.

However, there is another possible workaround that, sometimes, is

suitable for Oracle RAC environments. Edit the file protocol.ora or, for

older versions, sqlnet.ora, at the server side and add the following

directives:

  TCP.VALIDNODE_CHECKING = YES   TCP.INVITED_NODE = (Comma,separated,list,of,ALL,valid,clients, ...)

But, anyway, this workaround doesn't prevent valid clients from being

used as proxies. Valid clients can still exploit the vulnerability

regardless the VALIDNODE_CHECKING directive added as the client is a

valid node.

Then again, there is one more suitable workaround: If customer bought

(and enabled) Oracle Advanced Security feature clients can be configured

to use SSL/TLS. Thus, at both client and server side, the following

parameters must be changed in protocol.ora or sqlnet.ora:

  Client side: SQLNET.ENCRYPTION_CLIENT=REQUIRED

  Server side: SQLNET.ENCRYPTION_SERVER=REQUIRED

The value of these configuration directives must be REQUIRED and not

REQUESTED, as is pretty common, otherwise the attacker can answer to the

connection attempt answering that no SSL cipher is supported at the

server side (as the attacker's controlled box is for the client the

trusted database's server) and the client will reconnect without using

SSL. Hope this helps, folks!

Have a great weekend!

Carol Dacko
University of Michigan
On Thu, May 3, 2012 at 10:34 AM, Paul Drake <bdbafh_at_gmail.com<mailto:bdbafh_at_gmail.com>> wrote: Lu,
The vulnerability that you refer to is in the Oracle TNS Listener. It is not specifically in the Oracle database server software executable, oracle.exe.
If you are entitled to an upgrade to the 11g R2 version of the database server software, you could download and install 11.2.0.2, apply the 11.2.0.2 p17 patch (CPUApr2012), apply the OC4J patch, copy your existing listener.ora, sqlnet.ora and tnsnames.ora files from the existing %ORACLE_HOME%\network\admin to the newly installed 11.2.0.2 home and set the parameter "SECURE_REGISTER_LISTENER = (IPC)" in the listener.ora and fire up an 11.2.0.2 listener.
You'll still need to add a description using the IPC protocol in the listener.ora if one doesn't already exist and populate the parameter local_listener in each of the databases respective spfiles.

You could even use the 11.2.0.3 patchset (again if you are so entitled).

This would not protect the existing 10.2.0.x databases from the other vulnerabilities that have been fixed since the terminal CPU for 10.2.0.x issued last July.
It would protect them from the vulnerability which this thread mentions.

hth.

Paul

On Thu, May 3, 2012 at 10:19 AM, Jiang, Lu <Lu.Jiang_at_umassmed.edu<mailto:Lu.Jiang_at_umassmed.edu>> wrote:

> Sorry that was my typo, thanks Dimitre for pointing out. Still could not
> find the patch for Windows platform. I have submitted a SR for this.
>
> We have couple of 10g databases and currently have no plan to upgrade
> them. The new patch requires Extended Support service for 10g databases.
> Does anyone know how much it would cost for the Extended Support?
>
> Thanks,
> Lu
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org> [mailto:oracle-l-bounce_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org>]
> On Behalf Of Radoulov, Dimitre
> Sent: Thursday, May 03, 2012 4:28 AM
> To: Lu.Jiang_at_umassmed.edu<mailto:Lu.Jiang_at_umassmed.edu>
> Cc: oracle Freelists
> Subject: Re: Question on Oracle Security Alert for CVE-2012-1675
>
> On 02/05/2012 23:40, Jiang, Lu wrote:
> > Note 1453883.1 suggests to apply patch for bug 1288029. Only find the
> patch for Linux platform, Could not find anything for other platforms.
> Tried to search this bug from Bug Number or Bug Database on metalink,
> nothing returned. Will submit a SR for this once I get a chance.
>
> I believe the correct bug number is 12880299 (one more 9 at the end).
> I see the complete Oracle supported platform list on MOS.
>
>
> Regards
> Dimitre
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.completestreets.org/faq.html
http://safety.fhwa.dot.gov/ped_bike/docs/pamanual.pdf


--
http://www.freelists.org/webpage/oracle-l



--
http://www.freelists.org/webpage/oracle-l