Bug 961866 - IPA user password can be found in clear text in httpd logs.
IPA user password can be found in clear text in httpd logs.
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.0
All Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Martin Kosek
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-10 11:17 EDT by Marcus M. Moses
Modified: 2015-01-21 10:33 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-21 10:33:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marcus M. Moses 2013-05-10 11:17:08 EDT
Description of problem:
While trying to setup a proxy pass to the new reset_password.html page in IPA, I found that I wasn't able to actually change the password.  I decided to not proxy the page, but when I examined the httpd logs, I found that when the values are put in to the web page, the username, old password, and new password are printed in the access log.  

Version-Release number of selected component (if applicable):
3.0.0.26

How reproducible:
It will do this anytime you try to change the password.

Steps to Reproduce:
1. Go to the http(s)://youripaserver.com/ipa/ui/reset_password.html
2. Input username password and new password twice.
3. Examine the /var/log/httpd/access_log file.
  
Actual results:
The password is changed, but the data entered into the webpage is logged in the access log.

Expected results:
I would expect that if I go to the page (whether proxied there or not) that it would immediately ask me for my credentials and make the necessary changes without leaving username and password in the access log.

Additional info:
This is important for organizations that are having to keep logs for official records for government entities because it is a serious security issue to have user passwords viewable.
Comment 2 Vincent Danen 2013-05-10 12:20:46 EDT
Can you include the relevant /var/log/httpd/access_log entries (scrub the username/password of course).

I ask only because I've just created a new user and then followed your steps and I definitely do not see this:

From /var/log/httpd/access_log:

192.168.25.50 - - [10/May/2013:10:14:10 -0600] "POST /ipa/session/json HTTP/1.1" 200 147
192.168.25.50 - - [10/May/2013:10:14:10 -0600] "GET /ipa/ui/images/ipa-banner.png HTTP/1.1" 404 306
192.168.25.50 - - [10/May/2013:10:14:27 -0600] "GET /ipa/ui/reset_password.html HTTP/1.1" 200 2298
192.168.25.50 - - [10/May/2013:10:14:27 -0600] "GET /ipa/ui/reset_password.js HTTP/1.1" 200 4245
192.168.25.50 - - [10/May/2013:10:14:27 -0600] "GET /ipa/ui/images/ipa-banner.png HTTP/1.1" 404 306
192.168.25.50 - - [10/May/2013:10:14:40 -0600] "POST /ipa/session/change_password HTTP/1.1" 200 205
192.168.25.50 - - [10/May/2013:10:14:53 -0600] "POST /ipa/session/change_password HTTP/1.1" 200 155

And from /var/log/httpd/error_log:

[Fri May 10 10:14:27 2013] [error] [client 192.168.25.50] File does not exist: /usr/share/ipa/ui/images/ipa-banner.png, referer: https://ipa.mydomain/ipa/ui/reset_password.html
[Fri May 10 10:14:40 2013] [error] ipa: INFO: WSGI change_password.__call__:
[Fri May 10 10:14:40 2013] [error] ipa: INFO: WSGI change_password: start password change of user 'jtest'
[Fri May 10 10:14:40 2013] [error] ipa: INFO: 200 Success: Password change was rejected: Constraint violation: Password is too short
[Fri May 10 10:14:53 2013] [error] ipa: INFO: WSGI change_password.__call__:
[Fri May 10 10:14:53 2013] [error] ipa: INFO: WSGI change_password: start password change of user 'jtest'
[Fri May 10 10:14:53 2013] [error] ipa: INFO: 200 Success: Password was changed.

Do you have debug logging enabled or something?  The above is from a stock IPA (no changes to apache config) using ipa-server-3.0.0-26.el6_4.2.x86_64.
Comment 3 Vincent Danen 2013-05-10 12:25:34 EDT
As an aside, can you also double-check permissions on those files?  They should not be exposed to other users on the system; /var/log/httpd is mode 0700 and, while the files are mode 0644, due to the directory permissions they are not readable:

[root@ipa ~]# su - jtest
su: warning: cannot change directory to /home/jtest: No such file or directory
-sh-4.1$ cat /var/log/httpd/access_log
cat: /var/log/httpd/access_log: Permission denied
-sh-4.1$ cat /var/log/httpd/error_log
cat: /var/log/httpd/error_log: Permission denied
Comment 4 Marcus M. Moses 2013-05-10 12:49:17 EDT
(In reply to comment #3)
> As an aside, can you also double-check permissions on those files?  They
> should not be exposed to other users on the system; /var/log/httpd is mode
> 0700 and, while the files are mode 0644, due to the directory permissions
> they are not readable:
> 
> [root@ipa ~]# su - jtest
> su: warning: cannot change directory to /home/jtest: No such file or
> directory
> -sh-4.1$ cat /var/log/httpd/access_log
> cat: /var/log/httpd/access_log: Permission denied
> -sh-4.1$ cat /var/log/httpd/error_log
> cat: /var/log/httpd/error_log: Permission denied

I'm sorry, I should have been clearer.  This happens when you proxy the password change site from another site. Here is a sample of the access log (the username and password are nonsensical):

172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /images/ipa-logo.png HTTP/1.1" 404 322
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /json2.js HTTP/1.1" 404 311
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /ipa.css HTTP/1.1" 404 310
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /jquery.js HTTP/1.1" 404 312
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /reset_password.js HTTP/1.1" 404 320
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /images/ipa-banner.png HTTP/1.1" 404 324
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /reset_password.js HTTP/1.1" 404 320
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /images/ipa-logo.png HTTP/1.1" 404 322
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /images/ipa-banner.png HTTP/1.1" 404 324
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /password?username=2ewfwe&password=wef546u&new_password=j6786i7&verify_password=%2C78i67i6&submit=Reset HTTP/1.1" 200 2298
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /ipa.css HTTP/1.1" 404 310
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /json2.js HTTP/1.1" 404 311
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /jquery.js HTTP/1.1" 404 312
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /reset_password.js HTTP/1.1" 404 320
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /images/ipa-logo.png HTTP/1.1" 404 322
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /images/ipa-banner.png HTTP/1.1" 404 324
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /jquery.js HTTP/1.1" 404 312
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /reset_password.js HTTP/1.1" 404 320



And here is the proxy pass configuration on the proxy webserver named my.proxyserver.biz:

           ProxyPass /password https://my.ipaserver.biz/ipa/ui/reset_password.html
           ProxyPassReverse /password https://my.ipaserver.biz/ipa/ui/reset_password.html
           RewriteEngine on
           RewriteRule ^/password/(images|javascripts|stylesheets)(.*) /password/$1$2

The idea is to not allow the average user to see the address of the IPA server while allowing them to change their password on the IPA server.
Comment 5 Vincent Danen 2013-05-10 12:59:32 EDT
Ah, ok, that is clearer.  So the logging is taking place on your proxy server, not on the IPA server itself.

Looks like the solution would be to set the method to POST rather than not specifying it, which defaults to GET.
Comment 6 Martin Kosek 2013-05-13 01:55:24 EDT
Thanks for all the info. I will open an upstream ticket requesting this change.
Comment 7 Martin Kosek 2013-05-13 01:59:22 EDT
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3623
Comment 8 Petr Vobornik 2013-05-13 11:17:04 EDT
I think there are two issues:

1) The main caused by the proxy: The reset_password.html page doesn't have access to all its dependencies - mainly JavaScript files. Therefore it doesn't use JavaScript code for issuing an asynchronous POST request to `ipa/session/change_password` and instead it uses implicit method - get request to the page url - the problem this ticket is about.

2) The form in reset_password.html doesn't work well with JavaScript disabled or with missing dependencies. Usually it's not a problem because it's expected that it will have access to its dependencies. Disabling JavaScript is a topic for completely different discussion.
Comment 9 Marcus M. Moses 2013-06-03 13:11:09 EDT
I wanted to follow up to see if there was a patch I need to get in order to solve the problem or if it's still being worked.  Thanks.
Comment 10 Dmitri Pal 2013-06-03 15:56:50 EDT
There are no plans to fix it in near future because the situation can be easily avoided by properly configuring proxy as mentioned in #c8
Comment 11 Martin Kosek 2015-01-21 10:33:47 EST
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux.

Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as DEFERRED. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.

Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.

Note You need to log in before you can comment on or make changes to this bug.