[PHP-DB] suggestion about php ocilogon() oracle OCI FUNCTION

2003-10-27 Thread kss
I'm using php/oracle9.2 .
i cant' login into oracle db using ocilogon() as SYS user.
so, i examed oci8.c source.

above 9i , in order to login as SYS user
5th parameter of OCISessionBegin must be  OCI_SYSDBA(not  OCI_DEFAULT);

-
oci8.c
-
2315:   CALL_OCI_RETURN(OCI(error), OCISessionBegin(
2316:   svchp,
2317:   OCI(pError),
2318:   session-pSession,
2319:   (ub4) OCI_CRED_RDBMS,
2320:   (ub4) OCI_DEFAULT)); === 
OCI_DEFAULT|OCI_SYSDBA|OCI_SYSOPER

// OCI_SYSDBA -- in this mode, the user is authenticated for SYSDBA
// access.
// OCI_SYSOPER -- in this mode, the user is authenticated
// for SYSOPER access.
---

my suggestion !!

PHP ocilogon specification
resource ocilogon ( string username, string password [, string db] )
== new 4th parameter!
resource ocilogon ( string username, string password [, string 
db],sesson_mode=OCI_DEFAUL)
   
   --

ocilogon(SYS,change_on_install,mydb, OCI_SYSOPER );
   ---
is it possible ?( i'm poor at C programming).
sorry for my rudness  poor english.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] suggestion about php ocilogon() oracle OCI FUNCTION

2003-10-27 Thread Christopher Jones
kss wrote:

 I'm using php/oracle9.2 .
 i cant' login into oracle db using ocilogon() as SYS user.
 above 9i , in order to login as SYS user
 5th parameter of OCISessionBegin must be  OCI_SYSDBA(not  OCI_DEFAULT);
 my suggestion !!

 PHP ocilogon specification
 resource ocilogon ( string username, string password [, string db] )
 == new 4th parameter!
 resource ocilogon ( string username, string password [, string 
db],sesson_mode=OCI_DEFAUL)
 --
 ocilogon(SYS,change_on_install,mydb, OCI_SYSOPER );



It could be very useful to allow AS SYSDBA or AS SYSOPER connections.

However the suggested solution opens up a potential security hole.

If OCI_SYSDBA is used, then one authentication method used by Oracle
is to look at the group privileges of the OS user.  If the user is in
dba group on Linux, or ORA_DBA (or ORA_SID_DBA) on Windows, then
the authentication succeeds and you can login.  The username and
password fields are ignored - they may be bogus.  (There are a lot of
other cases where this authentication won't succeed, such as if the DB
is on a remote machine, but it is the security hole case that is
interesting and feasible.)
If Apache is started as the Oracle software owner it may inherit the
dba privileges.  Since Oracle installs its own Apache I would expect
some Apache instances to be in this position.  If the suggested oci8.c
code change is made, then PHP scripts will not need a valid username
or password to connect with the powerful AS SYSDBA privileges.  A
weakly coded script, perhaps using eval(), could be vulnerable to
remote attack on the database.
The scenario may be convoluted, but it is not particularly obscure and
could be expected to happen to a small number of users - when they
least expect it.
Any solution must balance the need for usability (being able to
connect AS SYSDBA) with security (stopping unauthorized users
connecting AS SYSDBA).
Some potential solutions:

  - Detect if the effective user that the PHP script is executing as
is in a privileged group and disallow AS SYSDBA/SYSOPER
connections or require another authentication method.  This is not
doable.  It is not feasible (i.e. not easy, portable, accurate) to
find out what the privileged group(s) used by Oracle are.
  - Make sure Apache is not started with a privileged group.  Even if
feasible this relies on education and user knowledge, so will only
be partially effective.  It also prevents even nice users from
connecting / AS SYSDBA and would require an Oracle password file
to be set up for access to local DBs.
  - Implement the suggested change to oci8.c and add yet another
configuration parameter to php.ini
oracle.allow_privileged_logon = Off

By default the parameter would prevent AS SYSDBA or AS SYSOPER
being used.  The code in oci8.c would need to check this
parameter.
This solution puts the security choice in the hands of the
installer.  It gives a convenient place to document and explain
the issue.
Chris

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php