Joe, The short answer is - Yes. If he has set a password on the listener service, then he is not vulnerable to this issue. He still need to verify that the listener password was set properly and that a strong password was used since the listener password very susceptible to brute-forcing. Another point to make with the database administrator is that you can apply the patch to the listener only. Meaning if the patch is causing the database to crash, you can skip applying the patch to the database, and only apply the patch to the listener. For proof of concept, you can download a free evaluation of AppDetective from www.appsecinc.com. It will tell you if the listener password is set and will try to crack it remotely (along with about 30 other checks for bufferoverflow and Dos attacks). It the listener holds up, you can rest a little easier. Regards, Aaron ____________________________________________ Aaron C. Newman CTO/Founder Application Security, Inc. Tel: 212-490-6022 Fax: 212-490-6456 E-mail: anewmanat_private Web: http://www.appsecinc.com - Protection Where it Counts - -----Original Message----- From: Joe Brown [mailto:joe_brown@senet-int.com] Sent: 11 January 2002 12:51 To: pen-testat_private Subject: Oracle TNS Listener Hello all, I was performing a pen test and found a version of Oracle TNS listener that reports being vulnerable to bid 2941. After contacting the client, the DBA told me that the patch crashed the apps on Oracle so, he implemented the Oracle workaround contained below. He now wants to know if that elminates the vulnerability until he upgrades to a non-vulnerable version. The workaround says to password protect the listener but, from what I have read, one doesn't need to authenticate to exploit this vulnerability. Unfortunately, with little knowledge of Oracle and without proof of concept code, I don't know if this workaround is successful and if this vulnerability has been eliminated. Any suggestions? (from Oracle) Workaround ~~~~~~~~~~ You must apply the patch as soon as it is available for your platform. However, an interim workaround until the patch is available for your platform is to password protect the listener. Once the listener has been password protected the SET LOG_FILE and SET TRACE_FILE commands in lsnrctl will not work without a password. For instructions on how to password protect the listener see the following: [NOTE:92602.1] How to password protect your listener In addition to setting the listener password you should also set up your permissions to limit who can has access to the listener.ora file and the lsnrctl executable. ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/ ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Fri Jan 11 2002 - 14:47:18 PST