Oracle today released an urgent, out-of-cycle security patch for a critical flaw in the Apache Connector component (mod_weblogic) of the Oracle WebLogic Server (formerly BEA WebLogic Server).  The CVE ID is CVE-2008-3257.  The CVSS 2.0 score for this vulnerability is 10 out of 10.  To put this into perspective, no previous Oracle vulnerability since Oracle began using CVSS base scores in October 2006 has scored a 10 and only 3 previous vulnerabilities (all related to Oracle Jinitiator) have scored 9 or higher.

The major risk associated with this vulnerability is that there are multiple published expliots, which allow for an attacker to compromise the integrity of the web server.

The COLLABORATE 08 conference went very well this year with excellent attendance and, as usual, high quality and informative presentations.  The aspect I especially like about COLLABORATE as compared to other conferences is that it is user-driven and almost all the 500+ technical sessions were devoid of any marketing speak or selling of products.

I presented 3 sessions between IOUG and OAUG, which were all well attended with over 150 people per session.  I guess security is really starting to become ingrained at many organizations.  I was somewhat surprised at the number of organizations relatively current with CPU patches based on the informal and highly unscientific "show of hands" surveys.

The PowerPoint presentations from my 3 sessions can be downloaded here -

Oracle Applications Users Group (OAUG)

Oracle E-Business Suite Critical Patch Updates: Insight and Understanding

Independent Oracle Users Group (IOUG)

Oracle Database Critical Patch Updates: Unwrapped

Real-life Database Security Mistakes

 

In the Oracle pre-release announcement for the April 2008 Critical Patch Update, one line in particular did catch my attention. I know Oracle has purchased many companies in the past few years.  So how many products does Oracle have?  Well, the CPU pre-release announcement states that --

"This Critical Patch Update contains 41 security fixes across hundreds of Oracle products."

I am assuming every Oracle E-Business Suite module counts as a separate product and potentially every database component, so there would be several hundred.  I wonder if Oracle has an official count of products somewhere.  There are 642 products listed in the Bug Search in Metalink.

Just something to think about when you are reviewing a CPU as it includes fixes for over 600 Oracle products.

For those of you not familiar with COLLABORATE or have not previously attended, the Oracle Applications Users Group (OAUG), Independent Oracle Users Group (IOUG), and Quest have teamed together to host a user-driven event with exceptional content.  COLLABORATE 08 is next week, Sunday, April 13 through Thursday, April 17 in Denver.  This year there will be over 500 technical sessions covering virtually every Oracle product. 

Integrigy's CTO, Stephen Kost, will be presenting three technical sessions, participating on a panel, and co-presenting in pre/post conference workshops.

Oracle Applications Users Group (OAUG)

Oracle Critical Patch Updates: Insight and Understanding
Tuesday, April 15, 2008
3:30 PM-4:30 PM

Securing the Oracle E-Business Suite Best Practices Panel
Moderated by Randy Giefer of Solution Beacon
Monday, April 14, 2008
8:00 AM-9:00 AM

Independent Oracle Users Group (IOUG)

120: Oracle Critical Patch Updates Unwrapped
Wednesday, April 16, 2008
1:30 PM - 2:30 PM

383: Real-life Database Security Mistakes
Thursday, April 17, 2008
11:00 AM - 12:00 PM

Pre and Post Conference OAUG Workshops

In conjunction with Jeff Hare of ERP Seminars, Stephen Kost is presenting a 1 hour session on Oracle Applications security at the "Oracle E-Business Suite Internal Controls and Security" pre and post conference workshops.  Integrigy is pleased to be collaborating with Jeff Hare on these workshops as he is one of the world's leading experts on Oracle Applications internal controls. 

Internal Controls and Security Best Practices in an Oracle Applications Environment

• Sunday, April 13 9:00 a.m. - 5:00 p.m.
• Thursday, April 17 9:00 a.m. - 5:00 p.m.

This workshop is an additional fee and requires a separate registration.  More information on the workshops is available on the OAUG COLLABORATE Website.

See you in Denver!

Since several new Oracle exploits were published this week, I thought it would be a good time to provide some background on exploits.

A topic of conversation whenever discussing Oracle security vulnerabilities is the complexity of exploiting such vulnerabilities.  Most Oracle professionals only have a cursory understanding of buffer overflows, SQL injection, cross site scripting (XSS), privilege escalation, etc., thus believe it is difficult to exploit many of the security bugs fixed in Oracle Critical Patch Updates.  Most Oracle vulnerabilities are very difficult to exploit solely based on the information delivered by Oracle.  Significant research, deep knowledge of the Oracle product, dissection of patches, and time are required to develop a new exploit.  Although, after developing a few exploits, the process becomes much easier and an experienced professional may be able to develop a fully functional exploit in a matter of hours.

However, all is not lost for the newbie, novice attacker.  Fortunately for those looking to reap ill-gotten fortunes from security-lax corporations, security researches routinely publish detailed exploit code for at least a handful of the security bugs fixed each quarter.  Any Oracle developer could easily execute almost all these published exploits.  With even limited knowledge of SQL and Oracle, possibly an accounts payables clerk who did a little homework could exploit some of these vulnerabilities.  (For those of you who think the accounts payable clerk example is far fetched should read the Secret Service's Banking and Financial Sector "Insider Threat Study".)

The published exploit code is not on some obscure web site, rather it is frequently published on a number of reputable web sites and popular mailing lists.  Simple Google searches will have numerous hits on phrases like 'oracle exploits'.  A recent trend has been to even incorporate evasion techniques into the exploit code, just in case an organization has deployed a database intrusion prevention system.

Two well organized sites with many published exploits are -

• Red Database Security

• milw0rm

Both these sites are worth a visit to understand how simple it is to use many of these published exploits and how important it is to properly protect databases, application servers, and applications.

From the Integrigy servers statistics, I have known that we get hundreds of visits a day from the Oracle proxy and cache servers.  Many days collectively the Oracle domains (.com, .uk, etc.) are number one.  The vast majority of the hits are on blog, RSS feeds, and our whitepapers.  But I have not known how Oracle actually uses this information internally.  Well, now I know someone is at least reading our comments and recommendations.

Last month, I posted about an issue we encountered during a number of recent Oracle Applications 11.5.10.2 assessments regarding the system profile option SIGNON_PASSWORD_HARD_TO_GUESS being incorrectly set.  This issue turned out to be related to the 11.5.10.2 maintenance pack instructions (Metalink Note ID 316365.1).  My comment was "Unfortunately, there is no step in Section 3 to make sure you set the profile option back to Yes."  Well, two weeks later Oracle has updated the instructions in Section 3 Step 2 to remind customers to reset the profile option.
 

US-CERT released an advisory on August 28, 2007 regarding multiple stack buffer overflows in the Oracle Jinitiator product (Vulnerability Note VU#474433/CVE-2007-4467). Due to limited public technical information on Jinitiator, no access to the Oracle support website, and maybe lack of cooperation from Oracle itself, the information released by US-CERT is incomplete as to the true scope of vulnerable Jinitiator versions, does not identify all vulnerable Jinitiator installs, and has only limited remediation steps.

All released Jinitiator 1.1.8 versions from 1.1.8.3 to 1.1.8.25 contain the buffer overflows in the Jinitiator ActiveX control – the US-CERT advisory only identifies versions through 1.1.8.16 as vulnerable. Each Jinitiator 1.1.8 version install uses a separate Microsoft Windows CLSID for the vulnerable ActiveX control to allow for multiple versions to co-exist, therefore, 15 CLSIDs must be used to disable/identify the vulnerable ActiveX controls rather than the single CLSID identified in the original advisory. In addition to disabling and uninstalling the vulnerable Jinitiator software, applications currently using vulnerable Jinitiator versions must be upgraded to use version 1.3.x which may also require upgrading the Oracle Forms software running on the server. It is important to note that each Jinitiator version (1.1.8.x) is a separate installation and there could be theoretically as many as 15 versions of Jinitiator 1.1.8 simultaneously installed on a client PC, even though only one or two versions are currently being used.

This vulnerability is different than previous Oracle vulnerabilities in that it is in the client web software.  Potentially, all client PCs that have accessed an Oracle Forms application like Oracle E-Business Suite 11i, Oracle Clinical, Retek, Sungard Banner, FLEXCUBE, or any custom Oracle Forms application could be vulnerable.  A targeted attack against your organization may be successful, especially as it requires only one unsuspecting user to click a URL.

DBAs are used to applying patches to fix Oracle security vulnerabilities, but not in this case.  This one requires some work first to identify what is out there and to work with the desktop management team to roll-out an uninstall type solution, especially since there may be 5 or more Jinitiator versions installed on a client PC.  Also, upgrades may be required to Oracle Forms 6i applications in order to support Jinitiator 1.3.1.x.

Integrigy has released a detailed analysis of these vulnerabilities to provide additional information and comprehensive remediation steps. The analysis can be downloaded at -

http://www.integrigy.com/security-resources/analysis/integrigy-oracle-jinitiator-vulnerability.pdf

The Federal Information Security Management Act (FISMA) of 2002 requires all government agencies to submit to the Office of Management and Budget an annual evaluation of IT security across the agency.  The overall results of these reports are complied and reported in the annual "Federal Computer Security Report Card", which scored the Federal government a D+. 

One aspect of the evaluation process relates to the use of configuration policies for Oracle.  We reviewed the publicly available agency reports to compile an Oracle-specific report card to see how agencies are doing with one small slice of FISMA.  Of the 24 agencies, 10 have published the entire FISMA report.

The results are not encouraging -- even agencies that achieved high overall scores have not implemented configuration policies for Oracle.  The overall Oracle grade is a D- for the Federal government.

FISMA is much maligned as mostly a paperwork exercise and does little in reality to improve overall information security.  However, most Oracle security experts agree that applying a well-defined configuration policy or security checklist can dramatically improve database security.  A key factor to the success of such a configuration policy is that it can handle application-specific exceptions.  There are a number of very good security checklists available including the Center for Internet Security Oracle Benchmark and the DoD Database STIG.

We looked at the FISMA and Oracle compliance because we believe using standard configuration policies can benefit most, if not all, Oracle implementations.

Reference:

FISMA and Oracle: 2005 Report Card