Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> TNS Poisoning
        
(Message started by: Pete Finnigan on May 29^th, 2012, 2:50pm)

Title: TNS Poisoning
Post by Pete Finnigan on May 29^th, 2012, 2:50pm

You might have heared about the latest Oracle security bug, the TNS Poisoning bug. It's a bug that exists since Oracle 8i.

What's the problem?
With this bug it is possible to register a listener on a remote location on an Oracle instance. The problem with that is that you can listen in on Oracle network traffic.

Oracle made it possible to add remote listeners to an instance for Oracle Real Application Clusters (RAC). Nowadays it is best practice in RAC systems to define (remote) so called SCAN listeners.

How big is the problem?
I don't know the CVSS score (the score that measures how severe a security bug is). Probably it's a pretty high CVSS score.

I've got questions of several people that never install Critical Patch Updates. Do that first, before you worry about this bug.

Why isn't the patch for this bug part of a Critical Patch Update?
The next Critical Patch Update will be available only in July. Very likely this bug will be solved in that CPU.

What is the solution at this moment?
There are three possible solutions: two for single instance databases (the usual setup) and one for RAC databases. See Oracle support note 1453883.1 for single instance and note 1340831.1 for RAC databases.

The short description: one of the solutions for single instance databases is a patch for bug 12880299. You can search patches on bugs in support.oracle.com. You’ll find it that way. The other single instance solution is changing the protocol with what de listener communicates with the database from TCP to IPC.

(I believe you also can turn of dynamic listener registration with a parameter. From then on you have to register a listener to the database manually.)

The RAC solution has to work around the fact that you actually want remote listeners to connect to a database. Remote SCAN listeners have become a best practice in high availability solutions. So Oracle had to think up a solution for that as well. And the solution is to protect listener-database communication with SSL. This solution is actually part of the Advanced Security option, but Oracle has allowed customers to use this particular Advanced Security functionality without having to pay for the license (if you don't have that license). If you implement any other functionality of the Oracle Advanced Security Option, you will have to pay for the license.

So if I choose the IPC solution, I don't need the patch?
It seems that way. I haven't tried it myself.

Why isn't there a patch for bug 12880299 on Windows?
Actually, there is: there is a patch for 11.1.0.7 and 11.2.0.3 on Windows (32 and 64 bit). It was issued later than the patches for Linux.

What's the impact of these solutions?
As far as I know: you have to restart one or more listeners.

Title: Re: TNS Poisoning
Post by Pete Finnigan on Jun 5^th, 2012, 12:38pm

Hi,

Quote:

I don't know the CVSS score (the score that measures how severe a security bug is). Probably it's a pretty high CVSS score.

7.5 according to https://blogs.oracle.com/security/entry/security_alert_for_cve_2012

Quote:

Very likely this bug will be solved in that CPU.

More likely will be fixed in next release

Quote:

(I believe you also can turn of dynamic listener registration with a parameter. From then on you have to register a listener to the database manually.)

Indeed, DYNAMIC_REGISTRATION_LISTENER=off sounds wise. You will then be back to the good old SID_LIST_LISTENER days... Probably the best protection

Title: Re: TNS Poisoning
Post by Pete Finnigan on Jun 6^th, 2012, 2:21pm

I've been reading a lot of Oracle CPU assessments by TeamSHATTER and I've learned that Oracle's CVSS scores can be lower due to their Partial+ scoring system. If not Oracle, the CVSS score would often be 9 or 10.

Quote:

Indeed, DYNAMIC_REGISTRATION_LISTENER=off sounds wise. You will then be back to the good old SID_LIST_LISTENER days... Probably the best protection

If this is the way things are going (less userfriendly is more secure) we'll be dealing with maxextent in no time. ;D

Title: Re: TNS Poisoning
Post by Pete Finnigan on Sep 3^rd, 2012, 4:15pm

Thanks Marcel-Jan for this post; sorry for the delayed reply. This has scoring being lowered has always been the case. I think it was Steve Kost who wrote about the scores and the calculations some years ago.

cheers

Pete

Title: Re: TNS Poisoning
Post by Pete Finnigan on Sep 3^rd, 2012, 5:07pm

Bouncing on your answer, I must said that disabling dynamic registration proved difficult, whenever you use standby, apex, xml and family, you need workarounds and lose on flexibility

Title: Re: TNS Poisoning
Post by Pete Finnigan on Sep 3^rd, 2012, 7:48pm

Thanks Laurent, for your feedback on this specifically for APEX, standby, XML etc; what workarounds did yout use and what was the trade off?

Kind regards

Pete

Title: Re: TNS Poisoning
Post by Pete Finnigan on Sep 3^rd, 2012, 8:11pm

actually for standby it is all benefit, you just need to edit your StaticConnectIdentifier with dgmgrl to use sid instead of service_name, which also permits smoother switchover from command line

for apex it is not a requirment to use the apex listener, you could use an apache

for xmldb my workaround was to not use xmldb :P Maybe other workaround exists

Title: Re: TNS Poisoning
Post by Pete Finnigan on Sep 4^th, 2012, 8:27am

Hi Laurent,

Thanks for the update, i hope it is useful for those who have not worked to solve this issue yet.

Thanks

Pete