Re: "ORACLE" won't go away as password for INTERNAL!!!

"PC User" <seeMessage_at_NOSPAM.com> wrote in message news:xEtx6.1803$iU.306808_at_news1.rdc1.mb.home.com...
> thanks for your reply and thanks for reminding me to rtfm. it is great
> that this issue has been resolved in a newer version. but what about
> thos who are stuck with an older version. do you know that oracle
> listens on port 1521, and anyone with little knowledge of the sid
> and oracle client software can connect to the database with full
> access. don't you see this as a problem? if not, please let me know what
> you do to make this security issue go away... in one of me tests, i was
> able to connect to a oracle server sitting in another city, over the
> internet
> using sql*plus. it let me in when i provided internal/oracle as
 credentials
> and i could do whatever i wanted. granted that people who leave their
> db servers so exposed on the internet may be deserve this kind of wakeup
> call, but what about the internal people and connections?
>

I think you're missing the point. Sybrand explained that connect internal/completeandutterrubbishi'vejustmadeup will work fine -because you've already logged on to the *operating system* and supplied valid credentials, to the point where Windows 2000 is happy to let you on to the box. There is thus no security problem at all: Fred Bloggs won't know your O/S login credentials, will he? So Fred Bloggs typing internal/completeandutterrubbishi'vejustmadeup will produce an error, because he won't have picked up membership rights of the W2K ORA_DBA group. Oracle will therefore check the password file for Internal's password, and will find a mismatch.

If you don't want the O/S credentials checked at all, even for yourself, then simply force Oracle to use a password file. That's done by removing all entries from the ORA_DBA local NT group (conceivably the ORA_sid_DBA group), and by changing the init.ora parameter remote_login_passwordfile to be either SHARED or EXCLUSIVE.

I think if Oracle was as wide open to security abuse as you seem to think it is, we might all have heard about it before now, don't you?

Regards
HJR
> thanks and regards,
> nn.
>
> p.s. i was extra carefull to not even use a single capitalized letter this
> time.... :-)
>
>
> "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message
> news:tcc5j3avhi8dda_at_beta-news.demon.nl...
> >
> > "PC User" <seeMessage_at_NOSPAM.com> wrote in message
> > news:Nrox6.1739$iU.277031_at_news1.rdc1.mb.home.com...
> > > Hi,
> > >
> > > I am running Oracle 8.1.6 on Windows 2000 server (SP/1).
> > >
> > > I have noticed that no matter what I do, the default password for
 Internal
> > > (i.e. "oracle") is *always* valid.
> > >
> > > Following is what I have tried:
> > > alter user sys identified by syssecret
> > >
> > > <I stopped the Oracle before I deleted and recreated the password file
 using
> > > orapwd. >
> > > orapwd file=pwdorcl.ora password=intsecret entries=5
> > >
> > > Following is what happens after above commands...
> > > Password "syssecret" is valid for user Sys.
> > > --what follows is realy interesting--
> > > Password "syssecret" is valid for user Internal. *AND*
> > > Password "intsecret" is valid for user Internal. *AND*
> > > ***** Password "oracle" is valid for user Internal.
> > >
> > > Of the last three, Internal accepting Sys' password makes sense as Sys
 and
> > > Internal are supposed to share the password. But, HOW DO I GET RID OF
 THIS
> > > "oracle" PASSWORD?
> > >
> > > Thanks and Regards,
> > > Nasir.
> > > nasirnoor_at_REMOVETHISsysspan.com
> > >
> > >
> >
> > This is just working as designed. In fact 'connect / as sysdba' would
 do.
> > This is the preferred syntax as internal is already obsolete and has
 been
> > removed in 9i.
> > The philosophy behind this is : if you are already a privileged user on
 the
> > server, an extra password in Oracle won't stop you.
> > If you really don't want this (and again : internal is no more in 9i) I
> > think you should remove the ora_dba local group from your server.
> > You might experience connect sys as sysdba with the old internal
 password
> > still works, but then again you might not. In that you need to
 explicitly
> > grant sysdba privilege to users.
> > I don't think you really need to SHOUT to resolve this problem; a little
> > reading in the NT specific Oracle documentation or the getting started
> > documentation would have resolved this issue also. It's a pity to see
 many
> > people waste so much time because they seem to forget reading the docs.
> >
> > Hth,
> >
> >
> >
>
>
Received on Sat Mar 31 2001 - 17:34:59 CST