#18391 [Csd->Opn]: Plaintext password revelation using KerberosV5 authentication

ID: 18391 User updated by: paul@myitcv.org.uk Reported By: paul@myitcv.org.uk -Status: Closed +Status: Open Bug Type: HTTP related Operating System: Linux 2.2.16-3 (Redhat 6.2) -PHP Version: 4.2.1 +PHP Version: 4.2.3 New Comment: I have just downloaded 4.2.3, md5sums match and I browse to line 437 of the file php-4.2.3/sapi/apache/mod_php4.c Why is this _still_ commented out? This bug still exists in the latest version despite reassurances it was fixed in CVS (see previous comment). Maybe I was wrong in assuming the CVS patch would be merged into the main source tree.... Previous Comments: ------------------------------------------------------------------------ [2002-07-17 13:41:07] sniper@php.net Please don't reopen this anymore. Here's what was changed: http://cvs.php.net/diff.php/php4/sapi/apache/mod_php4.c?r1=1.132&r2=1.133&ty=h&Horde=9ceccc2780159153ee91ad16f87bfb24 ------------------------------------------------------------------------ [2002-07-17 12:58:48] paul@myitcv.org.uk Thanks for the rapid reply! Very fast :-) Exactly how does ths CVS version fix this? For our temporary fix we completely commented out the following (from main/main.c): if (SG(request_info).auth_password) { php_register_variable("PHP_AUTH_PW", SG(request_info).auth_password, array_ptr TSRMLS_CC); } This code is not guarded in the CVS version, neither is the calling context.... what's changed? Paul ------------------------------------------------------------------------ [2002-07-17 11:27:28] sniper@php.net This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. ------------------------------------------------------------------------ [2002-07-17 08:39:26] paul@myitcv.org.uk .htaccess file as follows: ---8<--- SSLRequireSSL AuthType KerberosV5 AuthName Blah require valid-user ---8<--- Configure line as follows: ---8<--- './configure' '--with-apache=../apache' '--with-config-file-path=/usr/local/apache/conf' '--with-pgsql=/usr' '--with-xml' '--enable-safe-mode' '--enable-memory-limit' '--with-gd' '--without-mysql' '--with-imap=/usr' '--with-imap-ssl' '--with-kerberos' '--enable-versioning' '--with-jpeg-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-curl' ---8<--- Via PHP_AUTH_PW and PHP_AUTH_USER in the _SERVER var, users password is made available when AuthType is as above. According to the following quote from the page http://www.php.net/manual/en/features.http-auth.php: ---8<--- In order to prevent someone from writing a script which reveals the password for a page that was authenticated through a traditional external mechanism, the PHP_AUTH variables will not be set if external authentication is enabled for that particular page. In this case, REMOTE_USER can be used to identify the externally-authenticated user. So, $_SERVER['REMOTE_USER']. ---8<--- this should not be possible. Is KerberosV5 not an external authentication mechanism? On a shared system this behaviour is potentially disastrous as a malicious user could easily coax users to a secure, password protected page and snoop their _plain text_ passwords. Any thoughts? Paul J ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=18391&edit=1