Sven’s Technik-Blog

Laurent Schneider und mein Kollege Dirk Nachbar beschreiben in ihren Blogs, wie einfach es ist, die "Oracle Authentication Services for Operating Systems" zu installieren und zu konfigurieren. Im Prinzip 2 RPMs installieren - und das war's.

Die klingt schon sehr interessant - nicht nur für die Authentifizierung, auch als TNSNAMES-Ersatz (siehe Beispiel von Dirk).

Ich würde aber den produktiven Einsatz nur sehr bedingt empfehlen. Datenbank für "OID Light" ist Oracle XE, Version 10.2.0.1.

Für diese Version gibt es bis jetzt weder Patchsets noch CPUs. Das heisst, alle bekannten Sicherheitslücken dieser Version sind nicht gefixt - und können dadurch ausgenutzt werden.

In einem Artikel der Computerwoche wird beschrieben, dass die neue Version von Oracle Database 11g "dumme Programmierfehler" habe. Diese wären durch Schulungen zu vermeiden, da es sich um "simple Sicherheitslecks" handele.

Sicherlich hat Alexander Kornbrust damit Recht.

Es ist schon unverständlichen, dass Oracle immer wieder in dieselben Probleme hineinläuft. Meiner Meinung nach hätte man aber diese auch schon im Betaprogramm Oracle melden können und somit dem Endanwender viele Probleme (verzögerten Produktionseinsatz, Downtime durch patchen) ersparen können.

Wir als Trivadis haben uns als Betatester intensiv mit den Funktionalitätstests auseinander gesetzt und einige Fehler zurückgemeldet. Oracle hat z.T. sogar von uns gewünschte Features eingebaut. Nebst dem haben wir natürlich schon viel über Oracle 11g gelernt.

Habe heute abend mal die ersten Versuche mit der Produktionsversion von 11g gemacht.

Mein erster Kandidat ist natürlich mein eigenes Tool TvdExpert, da dort hunderte von DataDictionary-Views abgefragt werden.
Fazit: Sehr positiv - nur 2 kleine Änderungen waren notwendig, um es wieder lauffähig zu machen:

• In V$ASM_DISKGROUP gibt es das Feld UNBALANCED nicht mehr
• In DBA_USERS steht im Feld PASSWORD kein Hash mehr drin, sprich ich muss auf SYS.USER$ gehen, um zu checken, ob die Standardpasswörter geändert wurden:
  

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

Mit diesem CPU führt Oracle ein ganz neues Konzept ein: sogenannte napply CPUs (sprich N Apply). Dies sind Gruppen von Sub-Patches (sogenannte Molecules), die einzeln installiert werden können. Sollte eine Applikation Probleme mit dem gesamten CPU haben, können dann einzelne, für die Applikation unproblematische Gruppen eingespielt werden. Dadurch wird die Sicherheit verbessert, da nicht einfach der gesamte CPU nicht installiert wird - erzeugt aber wieder mehr Testaufwand...

Verfügbar wird dies für Unix/Linux-Systeme sein und nur für Datenbanken ab Version 10.2.0.3.

Gestern veröffentlichte Oracle das CPU für Juli 2007.

Wie bereits im Pre-Release-Announcement angekündigt, ist der höchste CVSS-Score 4.8 - ist also recht hoch. Im Bereich der Datenbank liegt er bei 4.2.
45 Security-Lücken wurden gefixt, 18 davon in der DB, einschliesslich einer im Bereich APEX.
Zwei Lücken sind von remote ausnutzbar ohne das eine Authentisierung (Username/Passwort) notwendig ist.

Wie schon in meinem Blog-Eintrag beschrieben, wird Oracle in Zukunft nicht mehr für alle Platformen Patches liefern, siehe dazu das Kapitel "Notice of On Request Model for Oracle Database and Oracle Application Server" in dieser Metalink-Note.

Die Patches werden teilweise erst am 24.07. verfügbar sein - wir werden dann wieder intensiv testen und berichten...

Es ist wieder einmal soweit: Oracle hat das "Pre-Release Announcement" für das CPU Juli 2007 veröffentlicht.

Der höchste CVSS-Score liegt bei 4.8 - ist also recht hoch. Im Bereich der Datenbank liegt er bei 4.2 - und dort sind 20 Security-Lücken gefixt wurden, einschliesslich einer im Bereich APEX.
Zwei Lücken sind von remote ausnutzbar ohne das eine Authentisierung (Username/Passwort) notwendig ist.

Und wieder etwas Werbung (für die, die wissen wollen, ob sie das CPU einspielen sollen) :
Der Trivadis CPU Report informiert Sie!

Aus dem Integrigy-Blog finde ich noch zwei Informationen interessant:

• Oracle will nicht mehr proaktiv für alle Plattformen das CPU entwickeln. Plattformen, die weniger nachgefragt sind, werden nur auf Anfrage entwickelt -> sprich es kann dementsprechend lang dauern, bis ein Patch verfügbar ist!
• Ausserdem wird Oracle 10.1.0.4 und 10.2.0.1 nicht mehr unterstützt.

Der vorherige Artikel (und die Beiträge meiner Kollegen) hat doch recht viele Reaktionen verursacht, u.a. den Beitrag "He that is without sin among you, let him first cast a stone at her" von Alex Kornbrust.

Ich gebe Alex vollkommen recht - alle die, die Datenbanken oder Programmierung lehren, sollten grösseres Augenmerk auf das Thema Security legen (aber wir geben uns Mühe ).

Auf Tom Kytes Blog ist darüber eine interessante Diskussion entstanden, auch Pete hat seine Meinung gesagt - ich glaube, da gibt's nichts mehr hinzuzufügen...

Es ist ja allgemein bekannt (hoffentlich), dass man seinen Code so schreiben soll, dass SQL Injection unmöglich ist (für die, die es nicht wissen, es gibt da im Internet viele gute Artikel dazu - oder fragen Sie uns...).

Man kann es aber auch ganz extrem machen - und dies sogar von einer Bank (siehe den Artikel Securing Secure Security).

Es ist schon nett, wenn man dem Benutzer sagt, welche Statements er nicht eingeben darf, damit es nicht zu SQL Injection kommen kann. Aber vielleicht kommt er dadurch erst auf dumme Ideen? Aber vielleicht fehlen noch ein paar Befehle?

Siehe dazu auch Pete's schönen sarkastischen Artikel...