How to Fix Oracle TNS Listener Remote Poisoning (CVE-2012-1675)

Oracle TNS Listener Remote Poisoning (CVE-2012-1675) means your database listener accepts service registrations from remote hosts, so an attacker can register a rogue instance under a real service name and intercept or disrupt new client sessions. Fix it by setting VALID_NODE_CHECKING_REGISTRATION_<listener>=ON in listener.ora, or restricting registration with SECURE_REGISTER, then running lsnrctl reload.

What the scanner is actually detecting

The finding is reported by Nessus as Oracle TNS Listener Remote Poisoning, plugin 69552 (family Databases). It is a remote check, not a version check. Tenable’s synopsis reads “It was possible to register with a remote Oracle TNS listener.” In other words, the scanner sent a service registration request to the listener port from its own address and the listener accepted it.

Registration is how a database instance tells a listener which services it offers. Normally the instance’s background process registers with a listener on the same host (through LOCAL_LISTENER) or with cluster listeners (through REMOTE_LISTENER). The listener cannot tell a real instance from a fake one, so the only control is where registrations are accepted from and over which transport.

Real-world risk

The issue was publicly disclosed in April 2012 as the “TNS Listener Poison Attack”. An attacker who can reach the listener port (1521 by default) and needs no database credentials registers an instance using the same service name as your production database. The listener then treats the rogue instance as another provider of that service and distributes new connections between the real instance and the attacker’s host. From there the attacker can proxy sessions (man in the middle), tamper with traffic, hijack sessions or simply drop connections.

Oracle rated it CVSS 2.0 7.5, remotely exploitable without authentication, and listed 10.2.0.3 through 10.2.0.5, 11.1.0.7 and 11.2.0.2 through 11.2.0.4 as affected supported versions, adding that earlier versions are likely affected too. The alert lists no patch number; its solution section points to configuration recommendations in two My Oracle Support notes (1340831.1 for RAC, 1453883.1 for non-RAC). Tenable marks public exploits as available.

Keep it in proportion: this is not code execution on the database server, and an attacker must already have network reach to the listener. That still includes any compromised workstation on a flat internal network, so a listener reachable from user subnets deserves prompt attention. On 12.1 and later, valid node checking is on by default, so a hit there usually means someone turned it off or widened the allowed nodes.

How to confirm it on the host

Log in as the listener owner (the oracle or grid OS user, or an Administrator on Windows) and identify the listener name, version and parameter file:

lsnrctl status LISTENER
lsnrctl version

The status output shows the Listener Parameter File and Listener Log File paths. Replace LISTENER with your real listener name everywhere in this guide; the parameter suffix must match it exactly (for example _LISTENER_ORCL for a listener named LISTENER_ORCL). Then look for the relevant parameters in that file:

# Linux / UNIX
grep -inE 'REGISTRATION|SECURE_REGISTER' /path/from/status/listener.ora

# Windows PowerShell
Select-String -Path "C:pathfromstatuslistener.ora" -Pattern "REGISTRATION|SECURE_REGISTER"

Interpret the result against the documented defaults:

• 11.2 with no VALID_NODE_CHECKING_REGISTRATION line: the documented default is off, so the listener is exposed unless SECURE_REGISTER is set.
• 12.1 and later with no line: the default is on (local addresses only). An explicit OFF or 0 brings the exposure back.
• SUBNET or 2: every machine in the listener host’s local subnets may register. If the scanner sits in one of those subnets, it will still succeed.

Finally, run lsnrctl services LISTENER and check that every instance and handler listed belongs to a host you recognize.

How to fix it

Back up listener.ora before any change, for example cp listener.ora listener.ora.bak.

Single instance: valid node checking for registration

Add the parameter for each listener. Per the Oracle Net Services Reference, ON (also 1 or LOCAL) allows only local IP addresses to register:

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = dbhost01)(PORT = 1521))
    )
  )

VALID_NODE_CHECKING_REGISTRATION_LISTENER = ON

If a database on another host legitimately registers with this listener through its REMOTE_LISTENER setting, list only those sources. Host names, CIDR ranges and IPv4 wildcards are accepted, and local addresses remain allowed:

REGISTRATION_INVITED_NODES_LISTENER = (apphost02.example.com, 10.20.30.0/24)

Apply the change without stopping the listener, then force the instance to register again:

lsnrctl reload LISTENER

-- in SQL*Plus as SYSDBA
ALTER SYSTEM REGISTER;

On 19c, lsnrctl reload -with_ha LISTENER keeps registered services available during the reload.

Oracle RAC and Grid Infrastructure

Do not hand-edit the SCAN listener entries. Oracle documents that from Grid Infrastructure 12c the listener agent overwrites VALID_NODE_CHECKING_REGISTRATION and REGISTRATION_INVITED_NODES for SCAN listeners, and that SCAN listeners accept registration only from the private network by default. Review and set the allowed external sources with SRVCTL instead:

srvctl config scan_listener
srvctl modify scan_listener -invitednodes "apphost1,apphost2" -invitedsubnets "10.20.30.0/24"

The config output lists Registration invited nodes and Registration invited subnets; remove any broad range that includes user or scanner networks. For node listeners managed by Clusterware, the agent sets VALID_NODE_CHECKING_REGISTRATION to SUBNET only if nothing is set. Follow My Oracle Support note 1340831.1 for the RAC procedure that matches your release.

Alternative: Class of Secure Transport (SECURE_REGISTER)

SECURE_REGISTER_<listener> accepts registration only on the listed transports and refuses all others. On a single instance the usual pattern is IPC, which cannot be reached over the network. Because the default LOCAL_LISTENER is a TCP address, the instance must be moved to IPC before you enforce, in this order:

1. Add an IPC endpoint to the listener and run lsnrctl reload LISTENER:

   LISTENER =
     (DESCRIPTION_LIST =
       (DESCRIPTION =
         (ADDRESS = (PROTOCOL = TCP)(HOST = dbhost01)(PORT = 1521))
         (ADDRESS = (PROTOCOL = IPC)(KEY = REGISTER_LISTENER))
       )
     )

2. Point the instance at that endpoint (SQL*Plus as SYSDBA):

   ALTER SYSTEM SET LOCAL_LISTENER='(ADDRESS=(PROTOCOL=IPC)(KEY=REGISTER_LISTENER))' SCOPE=BOTH;
   ALTER SYSTEM REGISTER;

3. Add SECURE_REGISTER_LISTENER = (IPC) to listener.ora, reload again, run ALTER SYSTEM REGISTER; and confirm the services are back in lsnrctl status.

For RAC, COST uses (IPC,TCPS) with Oracle wallets, which is covered step by step in note 1340831.1. Oracle added Advanced Security SSL/TLS to the Standard Edition RAC license and to the Enterprise Edition RAC and RAC One Node options so that customers can apply this without extra cost.

Releases 10.2 and 11.1

VALID_NODE_CHECKING_REGISTRATION is not in the 10.2 or 11.1 listener.ora references. SECURE_REGISTER is documented for 11.1; for 10.2, follow note 1453883.1 for your patch level. These releases are long out of Premier and Extended Support, so plan the upgrade alongside the workaround.

How to verify the fix and rescan

1. Run lsnrctl status LISTENER and confirm your services appear in the Services Summary with status READY.
2. Check that applications connect normally through the usual service names.
3. Rescan with Nessus and make sure the scan policy still covers the listener port, including any non-default port. Plugin 69552 should no longer report.
4. Open the listener log file shown by lsnrctl status and look for a rejected registration request from the scanner’s address during the rescan, typically logged with TNS-01182 (“Listener rejected registration of service”). That entry is positive proof the control is working.

What can break and how to roll back

For a structured approach to backout steps, see this guide to writing a patch rollback plan.

Common false positive reasons

• Scanner inside an allowed range. With SUBNET, or an invited list that contains the scanner’s network, the plugin succeeds from that vantage point. The finding is technically accurate for that subnet; tighten the list or accept the residual risk formally.
• Wrong listener name. The parameter was added for LISTENER, but the reported port belongs to a second listener such as LISTENER2 or a listener in another Oracle home.
• Edited but not reloaded. listener.ora changes do nothing until lsnrctl reload or a restart.
• Agent overwrote the edit. On Grid Infrastructure SCAN listeners, manual listener.ora changes are replaced; use SRVCTL.
• Bundled databases. Oracle notes that Fusion Middleware, Enterprise Manager and E-Business Suite include the affected database component. The hit is real; fix the embedded database listener.

For broader diagnosis patterns, see common causes of vulnerability scanner false positives.

FAQ

Is there a patch for CVE-2012-1675?

Oracle’s security alert does not list a patch number. It points to configuration recommendations in My Oracle Support notes 1340831.1 and 1453883.1, so in practice the remedy is listener configuration, plus upgrading off unsupported releases.

Does upgrading to 19c fix the finding?

Usually. From 12.1 the default for VALID_NODE_CHECKING_REGISTRATION is on, so a clean 19c listener rejects remote registration unless the setting was carried over as OFF or widened with SUBNET or invited nodes.

Can I just set DYNAMIC_REGISTRATION_LISTENER=OFF?

It does refuse all dynamic registration, but every service must then be defined statically in SID_LIST_LISTENER, since static registrations are unaffected. Valid node checking is the less disruptive control in most environments.

Is the listener port the only thing to restrict?

Firewalling port 1521 to application servers reduces who can attempt the attack, but it does not replace the listener setting. Apply both where you can.

Tracking this finding across many hosts

Across a large Oracle estate, the difficulty is proving which listeners were actually reconfigured and reloaded. SITEY, a self-hosted vulnerability management platform, imports Nessus results when you upload a .nessus export and can re-test an individual Nessus finding such as 69552 after a listener change. Where a legacy listener cannot be changed yet, record it through a risk acceptance process rather than excluding it from scans.

Sources

• Tenable: Oracle TNS Listener Remote Poisoning (Nessus 69552)
• Oracle Security Alert for CVE-2012-1675
• Oracle Net Services Reference 19c: listener.ora parameters
• Oracle Net Services Reference 19c: Listener Control utility
• Oracle RAC Administration Guide 19c: SRVCTL command reference