What is more dangerous? ALTER SESSION or OS Access?

Yesterday Pete Finnigan posted an entry „Is it possible to steal data with just ALTER SESSION?“ in his blog.

In this blog entry Pete describes various interesting possibilities to dump sensitive information from the database via ALTER SESSION, e.g. library cache, password hashes, …

It’s clear that „alter session“ offers many methods to dump data to the file system of the database server but without access to the (trace) file this information would be useless.

Pete talked also about the methods how to get such a trace file from the database server. According to Pete „a lot of“ databases where he performed a security audit had utl_file_dir set=* or directory objects to the tracefiles.

It would be interesting to know from Pete’s experience, on how many production systems a user with „alter session“ can access the tracefile  without asking the DBA for additional privileges, especially since „alter session“ was removed from the CONNECT role in 10g R2? 50% 20% 10% 1%?

I audited several hundred Oracle databases and so far only 5 of them had UTL_FILE_DIR=*. In my experience something less than 1%. At least far away from „a lot“. But probably our customer base has a different kind of database setup.
To steal the data from the server it is necessary to  have to privilege ALTER SESSION plus the right to get data from the file system.
The question is: What is more dangerous?  File Access from the database or the ALTER SESSION privilege?  It is clear that the best solution is to restrict/block both but this is not always possible.

I would vote for restricting/blocking file access because this will close many potential security holes. ALTER SESSION is only 1 problem.

A database with the setting UTL_FILE_DIR=* (btw utl_file_dir deprecated from Oracle since 9.2) has bigger problems than ALTER SESSION.

The important point in this discussion is to know all the different ways how a database user can access the file system of the database server. From my experience most DBAs do not know all documented ways how this can be performed.

I know 3 documented concepts in Oracle how to access the file system from the database.
* UTL_FILE_DIR / Directory Concept
* Java
* Oracle Text

Using these techniques (e.g. UTL_FILE_DIR=*, Java or Oracle Text) a database user can read any files (e.g. .bash_history, oracle password file, data_sources.xml) from the server.

This setting / Oracle object / privilege is required to access files. The file access can be done via packages (e.g. dbms_lob, utl_file, dbms_advisor, …), external tables or via a simple SQL statement (XMLTYPE). Especially XMLTYPE is dangerous because this is exploitable from a vulnerable web application without using packages. An example how to do this could be found on my overview page Oracle SQL Injection via Web.

Special java privileges are needed to read files from the operating system.This is not granted to PUBLIC. A sample how this could be done is available here.

Most DBAs are not aware of the possibility to read files via Oracle Text. By using the CTXAPP privilege plus a CREATE TABLE it is possible to read files from any directory of the database server.

— create a table
ot_format VARCHAR(6)

— insert the file (or URL!) you want to read into the table
INSERT INTO files VALUES (1, ‚c:\boot.ini‘, NULL);
— read the file/url by creating an Oracle Text index
CREATE INDEX file_index ON files(path) INDEXTYPE IS ctxsys.context
PARAMETERS (‚datastore ctxsys.file_datastore format column ot_format‘);

— retrieve the read data from the fulltext index
Select token_text from dr$file_index$i;

Sample Output

To harden a database there are many steps to perform. Blocking file and OS access is one of the most important steps. That’s why it is necessary for a DBA and also security researcher to know all ways how this could be performed.

The Oracle database is a huge product. If you know additional documented /undocumented ways how to access files do not hesitate to send me an email or to post a comment.

Leave a Reply

You must be logged in to post a comment.