Re: Will Oracle Security Alert for CVE-2012-1675 non-RAC fixes work with CMAN, etc?

From: dnrg <>
Date: Tue, 8 May 2012 08:10:14 -0700 (PDT)
Message-ID: <>

Thanks Martin. Based on what you said, your blog entry, and MOS ID 1455068.1, I believe we may already protected. Unless I'm not understanding things correctly. Does the mere presence alone of one or more CMAN rules routing traffic to specific instances rule out any hijacking? For example, we have rules for each instance having the following form:
 (rule    (src=*)
    (dst=<host containing oracle database of interest)
    (srv=<fully qualified service name of instance>)

The Node 1 and Node 2 verbiage in the MOS note I don't fully understand. What does it mean to have more than one "node" in this context? Some RAC tie-in? Failover / multiple CMAN instances? (we have a few).

I have a follow-on question; not sure if this should be a reply to other pre-existing posts on this vulnarability or create a new one. Any suggestions?

Anyway, I'm trying to apply patch 12880299 to an Linux-x86 box used only for CMAN and OID. There is no ASM / Grid Infrastructure. The host has both a "client home" and a "db home". And the listener runs out of the client home. On page 1 of the READ ME, Product Patched lists "RDBMS, ASM." Again, no ASM here.

So my question is this:

Do I apply the patch only to the "client home" since that's where the listener runs from? Or would it also be necessary to apply the patch again to the 11g database home?



 From: Martin Berger <> To:
Cc: oracle-l <> Sent: Monday, May 7, 2012 12:36 PM
Subject: Re: Will Oracle Security Alert for CVE-2012-1675 non-RAC fixes work with CMAN, etc?  

Hi Dana,

I asked the question already, and summarised ma answers here:

The original note is

Q1) from my SR: "CMAN uses a listener that does not support TCPS and cannot take advantage of the COST protections outlined in Doc ID 1453883.1 and Doc ID 1340831.1."

Q2) if you have source_routing, it's ok. otherwise it will kill your CMAN-setup.

IPC can only be used with listeners at the same node as PMON - don't know if this is the case in your CMAN setup.

I'd say a proper
        (rule=(src=*)(dst.220.8.114)(srv=*)(act¬cept)) with DST pointing to your local listeners i a quite 'cheap' and easy solution.


On Mon, May 7, 2012 at 5:00 PM, dnrg <> wrote:
> We don't use RAC but we do use CMAN for most connections (with Oracle instances ranging from to CMAN's not a product I understand very well.
> Q1) Will the fixes mentioned in MOS ID 1453883.1 (both TCP and IPC), as well as the DYNAMIC_REGISTRATION_LISTENER=OFF fix, work when CMAN is involved? Please excuse my ignorance here but should that make a difference?
> Q2) Sounds like DYNAMIC_REGISTRATION_LISTENER=OFF is the quickest way to fix this issue. Another poster asked if Oracle would support this. Does anyone
> Q3) Oracle's IPC fix shows the example name REGISTER. If we don't already have an IPC entry in various listener.ora files, does it matter what name we choose for this?
> Q4) Of the two official fixes, the 02-May-2012 version of MOS ID 1453883.1 states that "Either method works equally well but the TCP method is easier to implement." The 05-May-2012 version now states "Either method accomplishes the same goal but it is your choice which of them to implement." Are there any "gotchas" or things to be mindful of regarding the IPC method? With a large volume of listeners to remediate I'd prefer not to patch as a first approach. The IPC method doesn't look so bad and doesn't require patching. Am I missing anything important here in my decision about which method to use?
> Thanks very much.
> Dana
> --

Received on Tue May 08 2012 - 10:10:14 CDT

Original text of this message