Call: +44 (0)7759 277220 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Patrik Karlsson releases OScanner - A new free Oracle security vulnerability scanner"] [Next entry: "Two great papers and tools by Tim Gorman"]

Exploring Oracle November 2004 and REMOTE_OS_AUTHENT">Post on ORACLE-L : Exploring Oracle November 2004 and REMOTE_OS_AUTHENT



I noticed this post by Jared Still on the ORACLE-L list this evening which talks about a tip in the latest edition of Exploring Oracle (Nov 2004). It discusses a tip in the tip corner of page 5.

Jared sounds amazed at this tip which suggests setting REMOTE_OS_AUTHENT to TRUE to allow remote connections from a server other than the server Oracle is running on and creating an externally identified user.

I have not seen this edition so have not seen the exact text but like Jared i would suggest that this is a tip that should definitely not be followed. Allowing remote operating system authentication will allow anyone with a server (laptop, PC, whatever) connected to the network on which the database resides to spoof the database connection and gain access to your data without a password.

If you read this tip beware, allowing REMOTE_OS_AUTHENTICATION=TRUE to be set is going against basic Oracle security 101.

There has been 1 Comment posted on this article


November 17th, 2004 at 06:34 pm

Pete Finnigan says:

Regarding security problems involved with setting REMOTE_OS_AUTHENT to TRUE:

As the editor of Exploring Oracle, I take full responsibility for the tip that Jared has mentioned. The general concept mentioned in the tip of running a script locally (which of course doesn't require that parameter), without storing passwords, is still a sound one, and I should mention that the tip's author is an extremely experienced and gifted DBA. But I agree that the tip left a wrong impression by not supplying more context, and that's really my fault in this case. Although some third-party applications have been written in a way that requires this setting, it's important for people to understand the security risks involved, and it would have been better if we had mentioned these. I guess it just comes down to the fact that we're all human.

There are actually a number of other sources that mention how to set up remote OS authentication without mentioning the risks. For instance, look at www.dbaoncall.net/references/ht_os_auth_win.html.

At any rate, I appreciate that Jared has contacted me about this matter. The tip in question has been removed from our website (www.elementkjournals.com) so that we can cover this topic in a more complete way.

Although the December issue has already been printed, we do have a really outstanding article in the January issue by a talented security expert that will address this security problem, among others. This article will show you 20 ways to secure your database host. In addition, our March issue will cover the remote authentication problem in a more detailed manner. And, for the spring, we're lining up some really interesting security-related articles involving the 10g database.

Anyhow, I apologize if anybody has rushed out and set the REMOTE_OS_AUTHENT parameter on their production machine immediately after reading the tip. Generally, we advise that people don't run out and do something on their production machines without investigating whether the technique is appropriate for their particular circumstance. As always, feel free to contact us about any questions or comments you have about Exploring Oracle.

Thanks,
-Jonathan