Sven’s Technik-Blog

A new Audit Vault version is ready for download (for Linux, Solaris, AIX and HP Itanium) . Maybe some bugs are fixed...
I will test it

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

After the x86-Linux and the 32-bit Windows version now the x84-64bit Linux version is ready for download.

For more information see here.

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...

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.

Ausser angepassten Passwort-Profilen (siehe diesen Artikel) gehören noch weitere Änderungen am Default-Verhalten zu Oracles Initiative "Secure by Default".

So ist jetzt standardmässig Auditing eingeschaltet für folgende Operationen (Auszug aus der Oracle-Dokumentation):

Auch diese Massnahme ist aus Security-Sicht gut.

Aber für viele Firmen ist Auditing in der Datenbank etwas neues - etwas mit dem sie sich deshalb nicht beschäftigen wollen.
Read the rest of this entry »

"Secure by Default" nennt Oracle eine neue Initiative, durch die Oracle Database 11g out-of-the-box sicherer ist als eine vergleichbare 10g-Installation.

Dazu gehört u.a. auch "Fine-Grained Access für Netzwerk-Callouts", worüber ich hier schon berichtete.

Ausserdem wird beim Anlegen der Datenbank mit dem DBCA abgefragt, ob die "Enhanced default security settings" eingeschaltet werden sollen:

Wird diese Frage mit "Keep" beantwortet, wird das Default-Profile angepasst und der Wert PASSWORD_LIFE_TIME auf 180 (Tage) gesetzt. Das bedeutet, dass alle Benutzer nach 180 Tagen ihr Passwort ändern müssen.
Aus Security-Sicht ist das sicherlich gut (der Wert sollte eventuell sogar kleiner sein). Aber was machen dann alle Batchprogramme, Scripts, Programme mit fest kodierten Passwörtern (Application Server), ...? Abstürzen
Ich jedenfalls habe noch kein Programm gesehen, was in der Lage war, die Aufforderung zu erkennen und das Passwort selbständig zu ändern.

Deswegen - daran denken:
Vor dem Ablauf der 180 Tage ein spezielles Profile anlegen, im diesem PASSWORD_LIFE_TIME auf UNLIMITED setzen und (nur) den Benutzern zuteilen, die ihr Passwort nicht ändern können/sollen.

Übrigens, auch wenn Sie Ihre DB mit eigenen Scripts angelegen, gilt dieses Verhalten. Durch catproc.sql wird nämlich neu das Script secconf.sql ausgeführt...

Tanel Poder beschreibt in seinem Blog-Eintrag "Your read only accounts aren’t that read only", dass Benutzer mit ausschliesslich Select-Rechten Tabellen locken können. Damit besteht die Gefahr, dass diese Benutzer Applikationen komplett lahmlegen können. Tanel liefert auch einen (mühsamen) Workaround.

Durch diesen Bericht bin ich wieder einmal auf die Idee gekommen, zu testen, ob sich im "Readonly-Verhalten" von Oracle etwas geändert hat.
Read the rest of this entry »