In der Nacht zum 1. Mai 2012 veröffentlichte Oracle per E-Mail einen Security Alert zur Sicherheitslücke CVE-2012-1675. In diesem Artikel werden wichtige Informationen zusammegetragen und Lösungsmöglichkeiten diskutieret.
Worum geht es?
Die Sicherheitslücke betrifft die dynamische Registrierung beim Listener. Hierbei gleichen Listener ihre Services untereinander ab, um z.B. Loadbalancing für RAC durchführen zu können. Dies kann genutzt werden, um einen Listener einzuschleusen, der Verbindungen in eine unbekannte DB-Instanz „umleitet“. Szenarien wie das Ausspionieren von umgeleiteten Requests oder die Störung des DB-Betriebs durch fehlgeschlagende Verbindungen werden als Bedrohungen genannt.
Woher die große Aufregung?
Versucht man, verschiedene Informationen zusammen zu fügen, so bekommt man folgendes Gesamtbild:
Oracle hat das Problem mit dem letzten Critical Patch Update für behoben erklärt. Daraufhin hat der Entdecker der Lücke Einzelheiten zur Ausnutzung veröffentlicht. Schließlich stellte sich heraus, dass der Fix lediglich in der Codeline der noch nicht veröffentlichten Version 12 der Oracle Database steckte, nicht jedoch in allen produktiven Versionen. Da aber nun offiziell bekannte, einfach einsetzbare Mittel existieren, mit denen man einer produktiven Datenbank Schaden zufügen kann, wurde der oben angesprochene Security Alert veröffentlicht.
Weiterhin wurde kurze Zeit später der Tatsache, dass ein Workaraound für RAC-Systeme nur über die Nutzung des TCPS-Protokolls funktioniert, durch eine Änderung der Lizenzbestimmungen begegnet: Hätte man vor kurzem noch für die Verwendung des TCPS-Protokolls in Besitz einer Advanced Security Option sein müssen, so ist der Einsatz von TCPS (wohlgemerkt ausschließlich für die Anwendung des RAC-Workarounds für diesen Fall) für alle RAC-Kunden freigegeben. Dies gilt unabhängig von der eingesetzten Edition (Enterprise oder Standard). Alle anderen Features der Advanced Security Option (z.B. auch die Verwendung von TCPS für die Client/Server-Kommunikation) erfordern nach wie vor eine Lizenz.
Wie kann ich mein System schützen?
An dieser Stelle müssen diverse Fallunterscheidungen getroffen werden. Es gibt recht einfache Massnahmen, um ein System ab 10.2.0.3, das nicht als RAC betrieben wird, zu schützen. Bei RACs wird es etwas komplizierter, zudem muss ein bestimmter Patch eingespielt sein (Patch 12880299). Schließlich betrachten wir ältere Systeme, z.B. mit Version 9.2.
Single-Instance-Systeme ab 10.2.0.3 können dadurch geschützt werden, dass der Listener mit Hilfe des sog. COST-Parameters angewiesen wird, ausschließlich Registrierungen über IPC anzunehmen; damit sind alle Registrierungen von Remote-Knoten ausgeschlossen. (COST steht für Class of Secure Transport.) Hierfür ist kein Patch notwendig. Der Listener muss neu gestartet werden, es ist aber keine Downtime der Datenbank erforderlich.
Das geht bei RAC-Systemen nicht, da die Registrierungen per Definition auf anderen Knoten erfolgen. Daher muss der COST-Parameter auf TCP und TCPS eingestellt werden – bei TCPS wird durch Verwendung von Wallets sichergestellt, dass nur die gewünschten Instanzen sich registrieren. Alleine durch das Einspielen des erforderlichen Patches muss jede Instanz einmal gestoppt werden; allerdings ist keine Gesamt-Downtime erforderlich, da der Patch Rolling Installable ist. Die Verfügbarkeit von Patch 12880299 muss für das verwendete Release und die Plattform geprüft werden. Für die aktuellen Oracle-Versionen unter Windows ist der Patch in den Bundle Patches vom Mai 2012 enthalten. Patches für Versionen, die unter Extended Support laufen (z.B. 10.2), sind nur im Rahmen eines Extended Support Vertrages herunterladbar.
Für alle älteren Versionen muss die dynamische Registrierung von Instanzen beim Listener abgeschaltet werden. Im Gegenzug muss der Listener alle SIDs und Services in einer SID-Liste erhalten.
Das Abschalten der dynamischen Registrierung als „einfachster Workaraound“ ist nicht immer eine gute Idee, selbst wenn eine SID-Liste existiert. Auch Dienste, die etwa für APEX benötigt werden, nutzen die dynamische Registrierung. Daher ist die Verwendung des COST-Parameters grundsätzlich vorzuziehen.
Empfehlung
Die Workarounds für aktuelle Systeme sind vom Security Alert aus erreichbar. Sollte das Netzwerk, in dem die Datenbank betrieben wird, öffentlich zugänglich sein, z.B. per Internet, so sollten der passende Workaraound dringend durchgeführt werden. Das gilt ebenso, wenn das Netz z.B. über VPNs erreichbar ist oder eine gewisse Größe hat. Für RAC-Systeme mit älteren Versionen ist ohne Extended Support Vertrag kein einfacher Workaround verfügbar.