Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I'm a new DBA and I recently found out about the option of External Tables in Oracle using the PREPROCESSOR feature ( http://download.oracle.com/otndocs/products/database/enterprise_edition/utilities/pdf/xtables_preproc11g_1009.pdf ) Unfortunately, this feature, which seems quite useful in our lounge seems very dangerous, as someone with access to the OS (or remotely....) could exploit it to cause the database to get compromised, or even worst - the whole OS.

I have restricted the access to this feature to the minimum, and revoked any additional privileges which might allow outside access to the os (extproc, java, etc)

However, there are still times when we must use this feature, and this is where I ask you guys 2 main questions:

  1. How do you protect against malicious attacks using this wicked feature ?
  2. Assuming something has failed in the security mechanisms, what sort of ways are there to detect that someone used this feature in an evil way? What sort of queries (or content of them) could be seen ?

Thanks (:

share|improve this question
add comment

3 Answers 3

As mentioned there are two main vectors of compromise:

  1. OS Level compromise of the database.

    Mitigation:

    • Use the standard OS features, limitation by privilege, but a lot of files need to be protected.
    • Stop normal users from logging on, only allow access via sqlnet (recommended).
  2. SQLNet / SQL compromise of the database.

    Mitigation:

    • Limited privilege schemas used for web application (another user is the owner of the tables and grants specific access to the web app users).
    • Use packages to grant specific access to the features of the database with checks for misuse.
share|improve this answer
add comment

Oracle has had the capability of executing external code from SQL for a long time - EXTPROCs, data cartridges, and so on. You say

someone with access to the OS (or remotely....) could exploit it to cause the database to get compromised

But what does this even mean? Someone with access to the OS as the oracle user can access your DBFs directly (they're just files on the disk), can attach directly to the SGA, can make a backup and copy it off, can snoop the network traffic (as root). In the case of a malicious developer, the can do whatever they want in PL/SQL and wrap it. I don't see how you are introducing a new vulnerability by using this feature. If it makes your job or your user's jobs easier, go for it.

share|improve this answer
    
"someone with access to the OS (or remotely....) could exploit it to cause the database to get compromised" I meant that some application on our server has some remote SQL vulnerability we haven't found yet, what sort of queries would you expect to get ? I'm not talking about physical access or remote shell etc, as this is a dead end. This is not sqli-101, I know, I'm more interested on the malicious uses of this feature and how it can be avoided (even though you are restricting it to the minimum access as possible) –  dotdot Jan 12 '12 at 8:10
    
In the case of an EXTPROC (which I know the most about) it doesn't see raw SQL from the client, it is invoked with parameters which are Oracle datatypes, e.g. OCIDate, OCINumber, etc. –  Gaius Jan 12 '12 at 10:04
add comment

If a user has access to the OS and the the folder containing the PREPROCESSOR program then theoretically they can do anything the Oracle OS user can do.

  1. Prevent this by preventing this level of access to the OS.

  2. Monitor this by monitoring access to the OS and to the folder.

share|improve this answer
1  
bear in mind when doing this that Oracle database code like UTL_FILE for example can almost certainly access the pre-processor folder/directory as well so you might need to review access within the database as well as at the o/s level. –  Niall Litchfield Jan 12 '12 at 9:07
    
@Niall Of course, but as the OP was concerned about someone who already had access to the OS I didn't see it necessary to cover how that might have occurred. –  Leigh Riffel Jan 12 '12 at 14:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.