#18391 [Opn->Csd]: Plaintext password revelation using KerberosV5 authentication
ID: 18391
Updated by: wez@php.net
Reported By: paul@myitcv.org.uk
-Status: Open
+Status: Closed
Bug Type: HTTP related
Operating System: Linux 2.2.16-3 (Redhat 6.2)
PHP Version: 4.2.3
New Comment:
It never made it into the 4.2 branch; the fix *is* in
the main CVS tree, but it was due to an oversight (and
probably also because no one in the QA team has a Kerberos
authenticated system to test these things)
that it never got backported to 4.2.x.
Please accept our apologies.
Previous Comments:
------------------------------------------------------------------------
[2002-09-10 07:15:13] paul@myitcv.org.uk
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....
------------------------------------------------------------------------
[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
Thread (6 messages)