php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #57066 oci_pconnect password issue
Submitted: 2006-06-07 16:19 UTC Modified: 2006-08-05 16:56 UTC
From: ondrej dot subrt at email dot cz Assigned:
Status: Closed Package: oci8 (PECL)
PHP Version: Irrelevant OS: Window 2000/XP/2003
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ondrej dot subrt at email dot cz
New email:
PHP Version: OS:

 

 [2006-06-07 16:19 UTC] ondrej dot subrt at email dot cz
Description:
------------
I'm using OCI8 1.2.1. I want to use persistent connections, but I found security issue. In my case, each user log on to Oracle by own account (own username, password).

Proper user can log on correctly, but during his work with DB can other user reuse his persistent connection. Attacker can know only username but no password.

Also when proper user log out, this destroy only persistent connection in actual webserver/php child process. The other connections in the other childs processes are still active and therefore they can be reused by attacker (until connection reachs timeout).

I think, that problem is in HASHing (making unique ID) connection. I found in your source code (oci8.c:980) this:

smart_str_appendl_ex(&hashed_details, "oci8___", sizeof("oci8___") - 1, 0);
smart_str_appendl_ex(&hashed_details, username, username_len, 0);
smart_str_appendl_ex(&hashed_details, "__", sizeof("__") - 1, 0);
if (dbname) {
	smart_str_appendl_ex(&hashed_details, dbname, dbname_len, 0);
}
smart_str_appendl_ex(&hashed_details, "__", sizeof("__") - 1, 0);

It seems, that you hash connections only by username and DBname (if defined). But there's no password.

Reproduce code:
---------------
Call OciPConnProper.php:
<?php
 $conn = oci_pconnect('username', 'password', 'dbname');
 var_dump($conn);
?>

Then call OciPConnAttack.php:
<?php
 $conn = oci_pconnect('username', '..anything..', 'dbname');
 var_dump($conn);
?>

Expected result:
----------------
Result of OciPConnProper.php:
 resource(1) of type (oci8 persistent connection)

Result of OciPConnAttack.php:
 bool(false)

Actual result:
--------------
Result of OciPConnProper.php:
 resource(1) of type (oci8 persistent connection)

Result of OciPConnAttack.php:
 resource(1) of type (oci8 persistent connection)

Note: This become only in situation, when both requests come to the same child webserver/php process. Therefore you may need to repeat calling scripts more times to reproduce this one.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-06-08 18:40 UTC] ondrej dot subrt at email dot cz
I can give you some additional information about my configuration:
- Apache 2.0.55
- PHP 5.1.2, 5.0.5 as module, FastCGI (the same result)
- Oracle Instant Client 10.2; Oracle Client 10.2
- also try OCI8 from pecl4win.php.net (7.6.2006)

If you want to know something other, ask me, please. I'm sorry for my english.
 [2006-06-08 20:01 UTC] ondrej dot subrt at email dot cz
I found solution - edit oci8.c :

	smart_str_appendl_ex(&hashed_details, "oci8___", sizeof("oci8___") - 1, 0);
	smart_str_appendl_ex(&hashed_details, username, username_len, 0);
	smart_str_appendl_ex(&hashed_details, "__", sizeof("__") - 1, 0);
//*********************** NEW CODE ******************
	smart_str_appendl_ex(&hashed_details, password, password_len, 0);
	smart_str_appendl_ex(&hashed_details, "__", sizeof("__") - 1, 0);
//******************* END OF NEW CODE ***************
	if (dbname) {
		smart_str_appendl_ex(&hashed_details, dbname, dbname_len, 0);
	}
	smart_str_appendl_ex(&hashed_details, "__", sizeof("__") - 1, 0);

But I think, it will bee good to note in php documentation, that persistent connections are not secure! Or update code in next version.

What do you think?
Thank you for making this extension.
 [2006-06-13 17:26 UTC] ondrej dot subrt at email dot cz
Only changed Bug Type => Change Reuqest.
 [2006-08-05 16:56 UTC] tony2001 at phpclub dot net
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 26 09:01:29 2024 UTC