php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: paul at myitcv dot org dot uk
New email:
PHP Version: OS:

 

 [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-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 21:01:27 2025 UTC