Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> UTL_FILE_DIR set to *
        
(Message started by: Pete Finnigan on Jul 13^th, 2006, 6:58pm)

Title: UTL_FILE_DIR set to *
Post by Pete Finnigan on Jul 13^th, 2006, 6:58pm

Hello Everyone,

I manage the security for our project but have little understanding of Oracle and the ways it works. Thankfully I have a DBA who I believe 'gets it' and has alerted me to a potentially serious security vulnerability with something our developers are trying to do.

Our developers want to set UTL_FILE_DIR to '*'. Our DBA says this will allow any db user on any client to read/write to any directory the oracle OS user has permission to.

I've sanitized some information about what they intend below:
---from our devs---
APPLICATION has a dynamic changing directory for the generated files by the UTL_FILE package as below:
/<os_dir>/<customer_data_dir>/<customer_name>/<specific_data>/...
For each new CUSTOMER, we need to run a perl scrip to set up a new /<os_dir>/<customer_data_dir>/<customer_name>/.. directory. The developers have tried to set UTL_FILE_DIR =/<os_dir>/<customer_data_dir>/*, but it did not work. Looks like Oracle can only take either exact directory match or one wildcard * for all directories.

Therefore, for APPLICATION reports to work we have to set the UTL_FILE_DIR =* in the initORA. The same also applies for OTHER APPLICATION.
---end---

Assuming that my DBA is correct about this risk, can someone help me with an explanation I can give to our developers why this shortcut is unacceptable? They are the type to respond with "why would an internal user do something malicious?"

Thank you and please let me know if more description is needed.

D3

Title: Re: UTL_FILE_DIR set to *
Post by Pete Finnigan on Jul 13^th, 2006, 7:41pm

Hi

your DBA is correct. Setting utl_file_dir to "*" will allow any remote user who has the ability to use UTL_FILE to write or read to any file that the owner of the Oracle software has rights to access. There are many hacks that you can dream up using this ability that would let you escalate to SYS privileges.

The developers should re-think their design. They can also use DIRECTORY objects remember which can be controlled by better RBAC, e.g. you can control who can access the file system at the user or role level rather than globally as with utl_file_dir

cheers

Pete

Title: Re: UTL_FILE_DIR set to *
Post by Pete Finnigan on Jul 13^th, 2006, 8:31pm

Hi Pete,

Thanks for the confirmation about the DIRECTORY objects. Our DBA had found that as a possible solution just after my posting. It seems that there would still exist the possibility to read/write the Oracle directory (including binaries) but not the OS. I'm exploring the details to lock that down and audit the heck out of what gets left open.

Cheers,
D3

Title: Re: UTL_FILE_DIR set to *
Post by Pete Finnigan on Jul 14^th, 2006, 9:35am

Hi,

you should also be aware that UTL_FILE is only one of many built in packages that can be used to access files on the OS.

Good practice would be to ensure that the directory objects point to an OS directory structure that is isolated from the Oracle installation, i.e. if oracle is in /u01 and /u02 make sure directory objects are pointing only to /u04 and so on.

If you place contro0ls around who can create and access directory objects and also around where they point to you should be OK. For instance grant create directory to a new schema account. in that account create a package that manages the creation of the directory, hard code the pre-amble to the path - i.e. /u04 and then ensure no other schemas can create or alter directory objects. revoke create session from the package owner and grant access to just your create and alter directory package procedures to the application schema owner only. i.e make it harder for anyone to randonly call these procedures to access or chnage directories.

hth

Pete

Title: Re: UTL_FILE_DIR set to *
Post by Pete Finnigan on Jul 14^th, 2006, 3:37pm

Another possible advantage of directories is that you can give them general names and point to them from your code.

Suppose you have a production and a test site with different output paths. You can make a directory object called OUTPUT_DIR, which, on your production site might point to a different path than OUTPUT_DIR on a test site. You don't have to change your code, while with hardcoded utl_file paths you often have to.

Then think what happens when the directory structure has to change in, say, 3 years time from now, if you have paths hardcoded in your code?

Title: Re: UTL_FILE_DIR set to *
Post by Pete Finnigan on Jul 14^th, 2006, 5:47pm

Hi Marcel-Jan,

I agree with your view and I think you meant with utl_file_dir but I would still suggest that a filter is required in the controls around the access to create and alter directory objects to ensure that they are not created to point at sensitive directories such as the Oracle home or data files.

cheers

Pete

Title: Re: UTL_FILE_DIR set to *
Post by Pete Finnigan on Jul 19^th, 2006, 5:08am

AskTom has a java stored procedure for listing the contents of a directory. You could hardcode the /<os_dir>/<customer_data_dir>/ into that, and have it automatically CREATE DIRECTORY for all the individual data directories in there (where there isn't already a directory object for it).

http://asktom.oracle.com/pls/ask/f?p=4950:8:12177331569948952020::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:439619916584

As a side thought, what os account is running the perl script that creates the directory ?
Just thinking that a hard link created in that directory might be able to get to a file that really sits in another directory (eg the home directory of the oracle user). Not sure about symbolic/soft links. Probably best to test under your own OS anyway.