DB Link Passwörter Metadaten in 11.2.0.4
Seit der Datenbank Version 11.2.0.4 funktioniert das Auslesen der Beschreibungen für Datenbank-Links über DBMS_METADATA.GET_DDL nicht mehr. Statt des Passwort Hashes wird nun eine Bind Variable angezeigt.
Die Passwörter von Datenbank-Links wurden früher in der PASSWORD-Spalte der Tabelle SYS.LINK$ im Klartext abgelegt und waren einfach lesbar. In Version 10gR1 wurde der Zugriff auf diese Tabelle aus der Rolle SELECT ANY DICTIONARY entfernt, mit 10gR2 wurde die Spalte PASSWORDX eingeführt, die nun nur noch den Hash speichert. Mit der Sicherheit dieses Hashes steht es allerdings auch nicht zum Besten.
Während es in älteren Versionen möglich war, die komplette Link-Beschreibung inklusive der Passwort-Hashes in einer „BY VALUES“-Klausel auszulesen, sieht das Ergebnis in 11.2.0.4 so aus:
SQL> SELECT OWNER, DB_LINK, DBMS_METADATA.GET_DDL('DB_LINK',DB_LINK,OWNER) as DDL FROM DBA_DB_LINKS;
OWNER DB_LINK DDL
-------------- ------------ ----------------------------------------------------------
SYS TEST_LINK CREATE DATABASE LINK "TEST_LINK"
CONNECT TO "DBLINK_ACCOUNT" IDENTIFIED BY VALUES ':1'
USING 'TNSALIAS'
Der für den Link notwendige Hash steht allerdings immer noch in der PASSWORDX-Spalte der SYS.LINK$-Tabelle, und kann mit Hilfe von DBMS_CRYPTO recht einfach ausgelesen werden:
SQL> select
name,
userid,
utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)),
4353, (substr(passwordx,3,16))))
from sys.link$;
NAME USERID UTL_RAW.CAST_TO_VARCHAR2(DBMS_CRYPTO.DECRYPT
((SUBSTR(PASSWORDX,19)),4353,(SUBSTR(PASSWORDX,3,16))))
---------- --------- -------------------------------------------------------
TEST_LINK DBLINK_ACCOUNT GEHEIMESPASSWORT
Oft wird eine solche Möglichkeit benötigt, um Skripte zu erstellen, die Objekte wie Links zusammensuchen, um sie zu paketieren und für Deployment bereitzustellen.
Dieser Bug in der Datenbank Version 11.2.0.4 ist bei Oracle klassifiziert unter: Bug 18461318. Der Status dieses Bus steht allerdings auf „44 – Not Feasible to fix, to Filer„, was nicht sehr vielversprechend klingt.
Update 23.11.2017: Es findet eine Verschlüsselung, keine Hash-Wert-Berechnung, des Link-Passwortes statt, und diese lässt sich brechen.
Update: Oracle bezeichnet diesen Bug an anderer Stelle anscheinend als Security Fix:
Oracle: „This change has been made for security purposes. We cannot raise a bug and there is no workaround for this issue.“
Leider funktioniert das Neu-Anlegen eines Database Links mit der „BY VALUES“-Syntax aktuell nicht mehr.
Bei den aktuellen 256-Byte_Hashes (06%) führt diese Syntax zu einem „ORA-02153: invalid VALUES password string“.
Die „BY VALUES“-Syntax ist generell nicht mehr von Oracle unterstützt. In MOS Note: „Doc ID 1309705.1“ heißt es:
Bei 50-Byte-Hashes (05%) funktioniert das Anlegen noch, aber das Benutzen des Links scheitert mit „ORA-600 [kzdlk_zt2]“.
Oracle Support schreibt auf einen entsprechenden Service Request hin:
„This is expected and the correct output
Per bug 18461318 this was changed for security reasons.
Because of this, unfortunately we can’t make it possible to
output a complete db-link creation DDL command which will
automatically re-create the database link with it’s current
password, as we used to do in the past.
From now on we recommend that only Data Pump should be used to move database links
between databases while preserving their current password. Internally, Data Pump replaces the „:1″ with the correct
obfuscated database link password when it runs the DDL on the target system.
Or manually replace with password.“
Ich kann den Sicherheitsgewinn hier nicht nachvollziehen, da der Passwort Hash ja weiterhin im Dictionary in SYS.LINK$, und wahrscheinlich auch in der Data Pump Export Datei auslesbar ist.
Das Handhaben von Data Pump Dump Files in einer großen Umgebung, in der Dinge wie das Klonen von Datenbanken mit anschließendem Installieren der notwendigen Datenbank-Objekte automatisiert werden sollen, ist mehr als umständlich.
Und die Klartext-Passwörter zu verwalten, also irgendwo in einer Liste oder Tabelle aufzubewahren, wie Oracle vorschlägt, ist sicher eine wesentlich unsichere Lösung.
Meines Erachtens wird hier zu Gunsten scheinbarer Sicherheit die Sache verkompliziert und im Zweifel eher unsicherer gemacht.
Vielleicht sollte Oracle sich konsequent von (Klartext-)-Passwörtern verabschieden, und für technische Authentifizierung von Systemen untereinander grundsätzlich auf Zertifikate setzen.