M-A-O-L

Oracle’s Critical Patch Update July 2010 is out, with two easy to exploit DoS vulnerabilities in the Database network stack (although one on Windows only), and one critical vulnerability in the OLAP component – let’s just hope that this one opens the DB for attack if OLAP is actually linked in… because I guess most people’s Oracle will not have OLAP built in.

There are three more DB vulnerabilities – check the DB matrix in the appendix for details.

As usual our lucky French Eric Maurice gives the full rundown at the Oracle Security Blog.

Oracle’s Critical Patch Update Pre-Release Announcement – July 2010 arrived online, and the nice folks at Integrigy already published their standard CPU pre-release analysis.

I’m a bit worried about the number of highly critical Database alerts, four out of six vulnerabilities are remotely exploitable without authentication. Hope that’s just on Windows (as was often the case in the past), or in obscure features or functions that aren’t enabled by default.

Wo hat Oracle überraschenderweise angefangen, für alle Vulnerabilities einen CVE Identifier zu vergeben?

Was lässt Oracle Datenbank DBAs ruhiger schlafen, Oracle Application DBAs aber überhaupt nicht?

Worauf haben alle Oracle Spezis schon lange gewartet, und wird trotzdem niemand etwas deswegen machen?

Das Oracle Critical Patch Update – January 2008 ist raus, und ich denke, wir Datenbänker können aufschnaufen. Betroffen sind praktisch nur Add-On Komponenten wie XML-DB, Advanced Queuing, Spatial und UltraSearch. Einzig DB05 betrifft Upgrade/Downgrade, und ist über Oracle Net exploitable. Es handelt sich wohl um das Problem, dass man während dem Dictionary-Upgrade für einzelne Accounts das Default-Passwort verwenden kann. Der Workaround ist einfach: Listener abstellen während dem Upgrade. Ist sowieso empfohlen!

Das Oracle Critical Patch Update Pre-Release Announcement – January 2008 ist da, und alle Experten schreiben dasselbe:

• Zum ersten Mal mit 11g Patches
• Nur 8 DB Patches, kein Remote Exploit
• Aber einer davon kritisch (CVSS 2 Rating von 6.5)

Die Experten sind: Sven Vetter, Alex Kornbrust, und Stephen Kost. Na dann warten wir mal auf den nächsten Dienstag (PST).

David Litchfield in einer Mail an dbsec:

I’m seeking answers from Oracle DBAs and professionals about their feelings on security patches was hoping as many of you as possible would take the time to answer the 6 questions here : http://www.databasesecurity.com/survey.htm – I’d really appreciate it! Once I’ve got a good set of answers I’ll obviously post the details – and I’ll pester every so often until I do

Es sind nur ein paar wenige Fragen, und ich hätte mir mehr oder differenziertere Auswahl gewünscht (so sind Security Patches für mich alles drei: sehr wichtig, ärgerlich, und normal für DBAs), aber ich bin trotzdem gespannt auf die Auswertung.

Oracle hat das Critical Patch Update October 2007 Pre-Release Announcement veröffentlicht, und Stephen Kost von Integrigy hat es analysiert:

There are 5 remotely exploitable without authentication vulnerabilities, which are not typical of previous database vulnerabilities. Most previous database vulnerabilities require database authentication to exploit. Depending on the exact nature of the 5 remotely exploitable without authentication vulnerabilities, this quarter’s CPU could prove to be the most critical in the past 2 years.

Aber hoppla, das wäre nicht so gut.

Ausserdem ist zu vermerken, dass Oracle wie angekündigt jetzt CVSS 2 Metriken verwendet. Für die nächsten zwei CPUs werden weiterhin auch CVSS 1 Metriken mitgeliefert, damit der Umstieg einfacher fällt.

Slavik fragt sich: Oracle CPUs – Do We Care?

[...] do we care about Oracle CPUs at all? Oracle was getting a lot of heat from security researchers for not providing security patches or providing them with irregular intervals. Finally, Oracle is stepping up to the plate with the patches. They provide them on regular basis, they announce the the patch before issuing it so organizations can prepare for them. They are improving coding techniques and code vulnerability scanning tools. And after all that, customers are still not protected. The reason for this is that the database is an extremely complicated piece of software and is the life-line of the organization. An enterprise will need to test the CPU thoroughly before deploying and testing takes a lot of time (months). This is further complicated by the fact that many organizations have applications running on top of Oracle databases, and those applications are not “forward compatible” and certified by their vendors to run on future Oracle versions.

Er kommt zur Schlussfolgerung, dass wir jetzt schlechter dran sind als früher, weil die Megacorps ihre Datenbanken sowieso nicht patchen, die Hacker jetzt aber mehr Info über Bugs haben.