Sven’s Technik-Blog

During the last days we have tested the CPU very intensively.

Some information about it:

• I recommend applying it, if you use Oracle Application Express (APEX) 3.0. Because on iDefense it is described, how easy a security hole can vulnerable.
  You can upgrade to APEX 3.1 too.
• This is the first CPU without need for a newer version of OPatch (if you applied the patchset before). This means applying would be easier and the software would be more stable

Here is the first information about the next CPU.

Database:

• This CPU contains 17 new security fixes (including 2 for Oracle Application Express)
• The highest CVSS base score of vulnerabilities is 6.6.
  This is regarded as a high risk.
• Some very critical components are affected:
  • Audit
  • Authentication
  • Core RDBMS
  • Data Pump
  • Export
  • Oracle Net Services
  • Query Optimizer
  • ...
• This CPU includes fixes for Oracle Database 11g too.

Oracle Application Server:

• This CPU contains 3 new security fixes
• All of these vulnerabilities may be remotely exploited without authentication!
• The highest CVSS base score of vulnerabilities is 9.3 for clients and 6.6 for servers.
  This is regarded as a very high risk.

Oracle Enterprise Manager:

• This CPU contains 1 new security fix (in the Oracle Agent)
• The CVSS base score of vulnerability is 6.6.
  This is regarded as a high risk.

Wir haben das Patchset 10.2.0.4 auf einer Database Vault Datenbank getestet.

Obwohl in der Liste der Bugfixes kein Database Vault Bug erscheint, wurden zwei meiner kritischsten Bugs behoben
Einer ist noch offen - aber dieser ist wesentlich schwieriger (und nur als SYS) auszunutzen.

Da die OS Authentication für SYSDBAs wieder gesperrt ist, kann ich nun den Einsatz von Database Vault mit dem Patchset 10.2.0.4 empfehlen.

Trotzdem braucht es viel Datenbank- und Security-Wissen, um eine sichere Installation zu gewährleisten...

Nachdem im CPU Januar 2008 unsere gemeldeten Bugs nicht behoben wurden, habe ich heute von Oracle eine neue Antwort bekommen:

Die Bugs sind gefixt in 10.2.0.4 und 11.1.0.7 - und vielleicht auch in einen späteren CPU für ältere Versionen.
Also - warten wir weiter ab...

Wir sind gerade am intensivem Testen des CPUs. Einige Punkte dazu:

• Beim Einspielen des CPU in eine Oracle 10g Datenbank, wird automatisch ohne Abfrage der Oracle Configuration Manager (OCM) installiert:

  OPatch will now install the Oracle Configuration Manager in the Oracle Home.

  Wer dieses Feature nicht kennt: Damit können automatisch Informationen über die Datenbank, Umgebung, Fehler, ... an Oracle Support übermittelt werden...
  Zum Glück passiert dies jetzt nicht automatisch für alle Datenbanken - OCM muss dafür zuerst konfiguriert werden - und dies wird schon noch abgefragt:

  Do you wish to configure OCM at this time? (y/n)

• Für einen bekannten View-Bug müssen alle Views neu kompiliert werden (abhängig von der Oracle Version).
  Da dies einige Zeit braucht, gibt Oracle eine Reihe von Emfehlungen, wann es nicht notwendig ist. Z.B. ist es für Oracle 9.2.0.8 nicht notwendig, wenn (Zitat:) "Databases created with Release 11.1.0.6 or later" ...???...
• In diesem CPU wurde keiner der von uns gemeldeten Database Vault-Bugs behoben
  Unsere Empfehlung bleiben also leider bestehen

Es ist wieder so weit: Die Vorbereitungen für das CPU können starten.

Die ersten Informationen von Oracle sind hier verfügbar.

Ein paar Details dazu:

• Dies ist das erste CPU, welches auch Fixes für Oracle 11g beinhaltet
• Für Oracle 10g Database Vault finde ich keine Informationen, also scheinen unsere Security-Findings nicht behoben zu sein
• Für die Oracle Datenbank gibt es 8 neue Security Fixes, von denen keiner remote ohne Authentication ausnutzbar ist
  Mit einem CVSS-Score von 6.5 ist das Risiko aber sehr hoch
• Für den Application Server gibt es 6 neue Security Fixes.
  Mit einem CVSS-Score von 9.3 für Clients und 6.8 für Server ist das Risiko hier sehr hoch

Probleme können Anwender von Oracle-Versionen bekommen, die nicht das aktuelle Patchset einsetzen. So wird z.B. für Oracle Database 10.2.0.2 für Windows und Solaris kein Patch erscheinen oder dieser speziell angefordert werden müssen.
Siehe dazu das Kapitel "Planned Patches for Next CPU Release" im README des Oktober-CPUs.

Wie immer - wir werden das CPU testen und darüber berichten.

Mein Kollege Martin hat einen Rolling Upgrade mit dem aktuellen CPU getestet. Das Einspielen des CPU ging ohne Probleme (wenn der bekannte Bug mit Linux 64bit umgangen wird).

Damit aber die Datenbank die gesamte Zeit online zur Verfügung steht, müssen ein paar Sachen beachtet werden. Siehe dazu seinen interessanten Blog-Eintrag.

Es ist langsam wieder so weit, am 16. Oktober erscheint das nächste CPU. Das Pre-Release Announcement gibt schon mal einige interessante Informationen:

• 51 Security-Fixes für hunderte Oracle Produkte - wow
• Oracle ändert seine Risiko-Bewertung auf CVSS 2.0 Scoring
• Bereich Datenbank:
  • Der höchste CVSS-Wert ist 6.5 (4.2 für das alte CVSS 1.0 scoring) - entspricht also einem recht hohem Risiko
  • 27 Security-Löcher wurden behoben, davon sind 5 remote ohne Authentisierung ausnutzbar!
• Für OAS ist der höchste CVSS-Wert 6.8 (7.0 für das alte CVSS 1.0 scoring), also ein sehr hoher Wert
• Database Vault ist erwähnt, schauen wir mal, ob unsere gemeldeten Löcher geschlossen wurden...
• Oracle Database 11g hat noch keine Fixes

Wir werden dieses CPU wieder testen und berichten...

Patchlink hat eine interessante Studie veröffentlicht, nach der 54% der befragten Firmen "Zero-Day Vulnerabilities" als grösstes Sicherheitsrisiko bezeichnen und 29% kritische Updates innerhalb 2 Stunden einspielen.

IT managers reacted far quicker to emergency patches this year as compared to last, as 29 percent of organizations deployed critical updates within two hours during 2007 compared to just 14 percent in 2006. Seventy (70 percent) of IT managers completed fire-drill remediations within eight hours in 2007 compared to just 39 percent during the previous year.

Dies würde heissen, dass nahezu alle Firmen inzwischen das CPU Juli 2007 eingespielt haben. Dies widerspricht aber vollkommen meinen Erfahrungen
In vielen Firmen ist wochen- und monatelang später noch nichts passiert. Vielleicht gilt dies nur für Microsoft?

Interessant finde ich auch folgende Aussage:

"Most respondents (66 percent) said they spend an hour or longer every day monitoring security and IT consoles, administrating agents and updating security policies."

Schön wäre es, wenn es denn so sein...

5 Tage nach Erscheinen des Critical Patch Updates Juli 2007 wurde auf mehreren Blogs ein Exploit veröffentlicht, der die Sicherheitslücke DB17 (insert/update/delete auf Tabellen mit Nur-Lese-Recht) auf allen Datenbankversionen ausnutzt. Ich möchte dies bewusst nicht tun, da ich dies verantwortungslos finde.

Normalerweise haben DBAs 3 Monate zur Verfügung, um ein CPU einzuspielen, bevor gefundenen Sicherheitslücken veröffentlicht werden.
In grossen Unternehmen sehe ich diese Zeitspanne als richtig und wichtig an, da das Einspielen dringend getestet werden muss. Und wenn hunderte oder sogar tausende Datenbanken gepatcht werden müssen, braucht dies seine Zeit - und sicherlich mehr als 5 Tage.
Ausserdem waren zum Erscheinungstermin des Exploits noch nicht einmal alle Patches für alle Oracle-/Betriebssystemkombinationen verfügbar...