php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #18391 Plaintext password revelation using KerberosV5 authentication
Submitted: 2002-07-17 08:39 UTC Modified: 2002-09-10 07:39 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: paul at myitcv dot org dot uk Assigned:
Status: Closed Package: HTTP related
PHP Version: 4.2.3 OS: Linux 2.2.16-3 (Redhat 6.2)
Private report: No CVE-ID: None
View Developer Edit
 [2002-07-17 08:39 UTC] paul at myitcv dot org dot 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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-17 11:27 UTC] 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 12:58 UTC] paul at myitcv dot org dot 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 13:41 UTC] 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-09-10 07:15 UTC] paul at myitcv dot org dot 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-09-10 07:39 UTC] wez@php.net 
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.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 14:01:27 2025 UTC