Oracle-Datenbanken anfällig für eingeschleuste Lauscher

Nach dem letzten Patchday erklärte Oracle eine schwerwiegende Lücke der Oracle-Datenbank für gefixt. Der Entdecker veröffentlichte daraufhin konkrete Details. Doch obwohl nahezu alle produktiven Oracle-Installationen gefährdet sind, gibt es für die gar keinen Patch. Oracle-Datenbank-Administratoren sollten ihre Systeme deshalb möglichst bald selbst absichern.

Im Abspann der Dokumentation der Critical Patch Updates für April (CPU) bedankte sich Oracle bei Joxean Koret. Auf dessen Nachfrage erklärte man dem Sicherheitsexperten, dies bezöge sich auf das Melden einer schwerwiegenden Sicherheitslücke im Jahr 2008, die nun gefixt sei. Koret veröffentlichte daraufhin konkrete Details zu der Lücke und erklärte auch, wie sie sich ausnutzen ließe. Um sich zu schützen, empfahl er die Installation der aktuellen CPU-Patches. Allerdings stellte sich dann im Nachgang heraus, dass es für keine der aktuell verfügbaren Versionen der Oracle-Datenbank überhaupt Patches gibt. Die von Oracle referenzierten Sicherheits-Fixes bezogen sich ausschließlich auf die "Main Code Line", also das noch nicht verfügbare Oracle 12. Da aber nahezu alle produktiven Installationen betroffen sind, stehen jetzt fast alle Oracle-Administratoren im Regen und müssen schleunigst handeln.

Der Oracle Datenbank Server hat einen separaten Listener-Prozess, der normalerweise auf TCP-Port 1521 läuft. Er leitet die Anfragen der Clients an das eigentliche Datenbank-System weiter, das für die angefragte Datenbank-Instanz zuständig ist. Bereits seit Version 8i ist es möglich, über eine solche Netzwerk-Verbindung auch weitere Listener anzumelden. Der kann sich sogar für eine bereits existierende Datenbank-Instanz registrieren. Der bereits aktive Listener interpretiert das als neuen Knoten eines Oracle Real Application Clusters (RAC) und nutzt den neuen Listener für Load-Balancing. Sprich: Jede zweite Datenbank-Verbindung wird ab dann über den neuen Listener umgeleitet.

Alexander Kornbrust, Experte für Oracle-Sicherheit bei Red-Database-Security schätzt diese Sicherheitslücke als besonders ernst ein, "weil ein Angreifer remote und ohne Kennung auf dem Datenbankserver den Netzwerkverkehr der Datenbank über einen eigenen Server umleiten und danach mitlauschen kann. Lediglich die Oracle SID beziehungsweise Oracle Servicenamen muss ihm bekannt sein." Auf einen baldigen Patch von Oracle sollte man trotzdem lieber nicht hoffen. Kornbrust geht davon aus, dass deren Erscheinen noch länger als die 3 Monate bis zum nächsten CPU dauern wird. Denn gemäß der Oracle Patch Policy kommen jetzt erstmal die Patchsets wie das ebenfalls nicht verfügbare 11.2.0.4 an die Reihe und erst dann werden Security-Patches bereit gestellt. "Aus diesem Grunde dauert das oft 1-2 Jahre." klagt der Oracle-Spezialist.

Deshalb sollten Oracle-Admins möglichst bald selber aktiv werden, um ihre Installationen abzusichern. Wer kein Clustering nutzt, hat es da noch relativ einfach. Er kann über die Anweisung

dynamic_registration = off

in der Konfigurationsdatei listener.ora das nicht notwendige Feature deaktivieren. Schwieriger wird es in Cluster-Umgebungen. Dort kann man zum einen den Zugang zum Listener so einschränken, dass er weder aus dem Internet noch aus dem Office-LAN erreichbar ist. Darüber hinaus kann man in manchen Konfigurationen mit der Option TCP.VALIDNODE_CHECKING erzwingen, dass nur die in der Liste TCP.INVITED_NODE aufgeführten Systeme mit dem Listener sprechen können. Möglichst lange, zufällige SIDs und Servicenamen erschweren Angriffe zwar, können sie aber in der Regel nicht wirklich verhindern. Die nachhaltigste Möglichkeit, sich zu schützen, ist es, verschlüsselte Kommunikation via SSL/TLS zu erzwingen. Das wird allerdings für die meisten Admins kaum in Frage kommen, weil sich Oracle diese Option separat und richtig teuer bezahlen lässt. Weitere Informationen zu der Lücke finden sich in Joxean Korets Posting The history of a -probably- 13 years old Oracle bug: TNS Poison. (ju)