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.

3 Kommentare
  1. Jan Schreiber says:

    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:

    “Use of IDENTIFIED BY VALUES is reserved for internal Oracle use only.
    While earlier Oracle releases allowed the use of IDENTIFIED BY VALUES, this is not documented as being valid syntax.”

    Bei 50-Byte-Hashes (05%) funktioniert das Anlegen noch, aber das Benutzen des Links scheitert mit “ORA-600 [kzdlk_zt2]”.

  2. Jan Schreiber says:

    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.

Kommentare sind deaktiviert.