Re: OPS$LOGIN :security hole?
Date: Wed, 23 Dec 1992 07:20:30 GMT
Message-ID: <1992Dec23.072030.19046_at_cmutual.com.au>
Quite a lot of discussion have been going on about Oracle's security, OPS$LOGIN and SQL*Net. I am in the process of finishing a report for our Internal Audit Division that explains what the problems are and how to overcome them. If you interested in the report, I could post it to in the New Year. I do not pretend to know all the answers and could be wrong in some of my facts. If so, please correct me but no flames. In the short term, this is a summary and it applies to Oracle V6 only!
I hope the following information will clarify some of the misconceptions about Oracle security, OPS$LOGIN and SQL*Net eg
>The only way the ops$ account works without a password is when you are
>directly logged into the host server at the OS level. If you connect to
>the host via SQL*Net, the RDBMS will require entry of the password.
>I believe what oracle does with the autologin feature is just use the
>current
>user's operating system userid to come up with the ops$user account, then
>automatically log into that account using whatever password you gave it,
>What I do is make all accounts autologin, but assign a different password
>for each one and the passwords never change. No one ever needs to know
>what their password is, and no one can log into anyone else's account
>since they don't know what the oracle password is (unless, of course, they
>know the person's operating system password and log into that).
>IN UNIX (sunos4.12) the conventions
>sqlplus /
>sqlplus OPS$user/bogus
>will both work
You need to quote the OPS$user/bogus with 'OPS$user/bogus'
>The only way the ops$ account works without a password is when you are
>directly logged into the host server at the OS level. If you connect to
>the host via SQL*Net, the RDBMS will require entry of the password.
Not true. This is probably the case at your site because your DBA has chosen so.
Point 1
ANY OPS$LOGIN account can change its oracle password by using the command.
'grant connect to ops$login identified by password'
So no matter what password the DBA gives you, you can always change it.
Point 2
'sqlplus / ' works only is you have an Oracle OPS$LOGIN in the database.
Point 3
On UNIX, sqlplus or any Oracle programs for that matter will examine and use your 'User login name' not the User ID ie UID, for the OPS$LOGIN on the server where the database your are trying to access resides. That is, LOGIN is your Op/Sys Login Name.
Point 4
It is possible to login across the network using
'sqlplus /_at_T:machine:SID'
without specifying a password.
To be able to login across the network using ops$login you MUST have an OPERATING SYSTEM account on the Server and the server database must have an Oracle OPS$LOGIN user.
Point 5
It is possible to shutdown or create havoc on a remote database across the network using the same principle as above. What it all boils down to is
- does the remote server have an op/sys account name the same as the one you are using on your local server
- does the op/sys account belong to the DBA group on the remote server
So how to you get around
1. OPS$login across the network
ANSWER: Start up orasrv with 'opsoff'
2. Unauthorised DBA access across the net
ANSWER: Start up orasrv with 'opsoff' AND 'dbaoff'
Point 6
Even with opsoff, you may still use the op$login if you are connecting to a local database.
The real security issue is not to do with OPS$LOGIN but unauthorised DBA commands across the network like 'shutdown immediate' and 'connect internal'
I have validated the above points at my site and it may differ from yours. If you find any of the points incorrect please email me .
thanks
tony
-- _____ ________ / ____ |Tony Jambu, Database Administrator /_ __ /_ __ / |Colonial Mutual Invest Mgmt Aust (ACN 004021809) /(_)/ ((_/ \_/(///(/_)/_( |EMAIL: TJambu_at_cmutual.com.au \_______/ |PHONE: +61-3-6418448 FAX: +61-3-6076198Received on Wed Dec 23 1992 - 08:20:30 CET