Sicherheitslücken in Oracle Database Vault

Sven Vetter schreibt in seinem Technik-Blog, dass es per dynamischen SQL sehr einfach möglich sei, Database Vault auszutricksen. Das wundert mich nicht, da wir schon vor Monaten Sicherheitslücken in Database Vault an Oracle secalert gemeldet haben. Nachträglich solch ein Konzept einzuführen, ist natürlich nicht einfach und vor allem nie fehlerfrei. Die aktuelle Version dient wohl eher dazu, Know-How aufzubauen und vor allem die internen Prozesse, wie z.B. die DBAs arbeiten, an das Produkt anzupassen.

Vielleicht erfahren wir von Sven seinem Vortrag auf der DOAG mehr über diese Lücken.

Weiterhin schreibt Sven, dass „Es sind zu viele Security Lücken vorhanden, die das Lesen und Ändern von vertraulichen Daten als Datenbank- oder Betriebssystemadministrator zulassen – genau das aber verspricht dieses Produkt zu unterbinden„.
Dies ist so nicht richtig. Oracle schreibt dazu: „Oracle Database Vault can prevent highly privileged users, including powerful application DBAs and others, from accessing sensitive applications and data in Oracle databases outside their authorized responsibilities„. Oracle spricht nicht von Betriebssystemadministratoren.

Database Vault wurde NUR dazu entworfen, einen Benutzer mit DBA Berechtigungen OHNE Betriebssystemzugriff (direkt bzw. indirekt (z.B. dbms_scheduler)) einzuschränken (z.B. select any table oder Passwort Änderungen). Sobald man Betriebssystemzugriff (erlangt) hat, ist es trivial, Database Vault auszutricksen/ zu umgehen, da man beispielsweise als Betriebssystembenutzer Database Vault einfach ausschalten kann (wird für das Einspielen der CPUs benötigt). Dies ist aber keine Lücke, sondern Teil der Architektur von Database Vault.

7 Responses to “Sicherheitslücken in Oracle Database Vault”

  1. Sven Vetter sagt:

    Hallo

    >>Vielleicht erfahren wir von Sven seinem
    >>Vortrag auf der DOAG mehr über diese Lücken.

    Ich werde den Vortrag nicht halten, sondern mein Kollege Stefan Knecht. Mal sehen, was dann noch über Lücken zu berichten ist, ich hoffe weniger…

    Dafür werde ich einen Vortrag über Audit Vault halten.

    Gruss
    Sven

  2. […] Vault ist noch nicht gut genug für Trivadis. Aber Alex springt zur Ehrenrettung ein, und wehrt sich für Database […]

  3. Alexander Kornbrust sagt:

    Keine Sorge. Ich werde nicht vom Oracle Product Management bezahlt oder gesponsert. Finde weiterhin Fehler bei Oracle, Quest, BMC, …

    Database Vault ist z.Z. noch ein Spielzeug. Leider wird es oft falsch positioniert/verkauft („Das hilft gegen/für SOX“). Es ist ein Framework, das Applikations-DBAs und mächtige Accounts davon abhalten soll, auf andere Daten zuzugreifen. Vielfach wird auch der Aufwand zur Administration und Implementation unterschätzt. Durch die „Segragration of Duty“ benötigt man wesentlich mehr Personal als im normalen 24×7 Betrieb. Auch die normalen Workflows in großen Unternehmen (z.B. ticket-System für Oracle-problem) klappen ohne Änderung damit nicht mehr. Und das ist oft das eigentliche K.O. Kriterium.

    Sven: Werde mir beide Vorträge anhören.

  4. Hallo Alex

    Ich bin nicht ganz einer Meinung mit dir:

    „Database Vault wurde NUR dazu entworfen, einen Benutzer mit DBA Berechtigungen OHNE Betriebssystemzugriff (direkt bzw. indirekt (z.B. dbms_scheduler)) einzuschränken (z.B. select any table oder Passwort Änderungen). Sobald man Betriebssystemzugriff (erlangt) hat, ist es trivial, Database Vault auszutricksen/ zu umgehen, da man beispielsweise als Betriebssystembenutzer Database Vault einfach ausschalten kann (wird für das Einspielen der CPUs benötigt). Dies ist aber keine Lücke, sondern Teil der Architektur von Database Vault.“

    Das mag so schon stimmen. Nur finde ich das Produkt sinnlos, wenn es während einer LAUFENDEN INSTANZ einfach so on-the-fly ausgeschaltet werden kann. Denn nur wenige Umgebungen bieten eine so starke Trennung von OS und DB Zugriff, so dass man dies einfach ignorieren könnte. Wenn das Produkt sich jemals am Markt durchsetzen will, muss Oracle auch diese Probleme beheben.

    Und in den aktuellen Versionen (11g habe ich noch nicht getestet) kann die Vault Option deaktiviert werden, ohne dass irgend jemand etwas davon bemerkt.

    Mehr dazu an der DOAG 😉

    Stefan P Knecht

  5. Sven Vetter sagt:

    Stefan – verrate nicht so viel 😉

  6. Alexander Kornbrust sagt:

    Hallo Stefan

    Deine Bedenken wg. Database Vault teile ich. Je nach Szenario kann Database Vault sowohl zusätzliche Sicherheit aber auch zusätzlich Komplexität hinzufügen.

    Es ist ein allgemeines (oft übersehenes Problem), dass alle Security-Features, sowohl SICHER aktiviert bzw. als auch deaktiviert können müssen, damit ein Hacker Features nicht ein bzw. ausschalten kann.

    Ein gutes Beispiel ist Transparent Data Encryption (TDE). Jeder DBA (oder Hacker mit DBA-Rechten) kann TDE (alter system set encryption encryption key) aktivieren (was dann natürlich eine Lizenz-Verletzung ist, falls kein ASO lizensiert ist) und anfangen, Tabellen zu verschlüsseln.

    Solange die DB online ist, ist alles in Ordnung. Sobald die DB aber neu gestartet wird, wird ein Passwort verlangt. Das hat aber nur der Hacker…. Ohne Passwort sind die Daten zwar sicher (da verschlüsselt) aber nicht mehr zugreifbar.

    Auch hier ist das Problem, dass ein Features einfach verwendet/eingeschaltet/ausgeschaltet werden kann, ohne Seriennummer, Zertifikat, …

    Grüße

    Alex

  7. […] ich in den Blogs von Markus und Alex zitiert und korrigiert werde, noch eine genauere Darstellung zu dieser Aussage: „Es sind zu viele […]

Leave a Reply

You must be logged in to post a comment.