Bug 1174458 - Trusted Forest bind_pwd is logged in clear text
Trusted Forest bind_pwd is logged in clear text
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance (Show other bugs)
5.3.0
All All
low Severity medium
: GA
: 5.5.0
Assigned To: abellott
Kyrylo Zvyagintsev
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-15 16:22 EST by Josh Carter
Modified: 2015-12-08 08:01 EST (History)
8 users (show)

See Also:
Fixed In Version: 5.5.0.1
Doc Type: Bug Fix
Doc Text:
In the previous version of CloudForms Management Engine, the password of the administrative user used to setup a trusted Active Directory forest would be logged to the evm log when saving the settings for the trust. This bug was a result of faulty programming logic, and was fixed by correcting the code. The administrative user's password is no longer logged when setting up a trusted Active Directory forest in the new version of CloudForms Management Engine.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-08 08:01:44 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)
config (92.51 KB, image/png)
2015-07-21 15:07 EDT, Josh Carter
no flags Details

  None (edit)
Description Josh Carter 2014-12-15 16:22:34 EST
Description of problem:

when you add a trusted forest that the password is shown in clear text in the logs when the settings are saved.

evm.log-20141210.gz:[----] I, [2014-12-08T19:32:05.581849 #2253:1137ea4]  INFO -- : <AuditSuccess> MIQ(Common.settings_update_save) userid: [admin] - VMDB config updated (basedn:[] to [dc=example,dc=com], bind_dn:[] to [Administrator], bind_pwd:[*] to [*], ldaphost:[[]] to [["10.13.211.68"]], ldapport:[636] to [389], mode:[ldaps] to [ldap], user_proxies:[[]] to [[{:ldaphost=>"example1.com", :ldapport=>"389", :basedn=>"dc=example1,dc=com", :bind_dn=>"test", :bind_pwd=>"test"}, {:ldaphost=>"example2.com", :ldapport=>"389", :basedn=>"dc=exampe2,dc=com", :bind_dn=>"test", :bind_pwd=>"test"}]])

Version-Release number of selected component (if applicable): 5.3.1 and upstream master 


How reproducible:
very

Steps to Reproduce:
1. add a trusted forest 
2. evm log will show plain text password
3.

Actual results:


Expected results:


Additional info:
Comment 2 abellott 2015-04-29 17:23:17 EDT
Ok, I've tried with a 5.4 build 25. With both Role settings as well as adding a trusted forest, the password look filtered in the log, i.e. (bind_pwd shown as [*] and [FILTERED]).

Josh, please retest with latest 5.4 when you get a chance and update the ticket accordingly. Thanks.
Comment 3 Josh Carter 2015-07-21 15:07:22 EDT
This still is a issue on the current release. 

[----] I, [2015-07-21T15:05:26.013679 #977:8f1eac]  INFO -- : <AuditSuccess> MIQ(Common.settings_update_save) userid: [admin] - VMDB config updated (user_proxies:[[{}]] to [[{:ldaphost=>"ad.example2.com", :ldapport=>"389", :basedn=>"dc=example2,dc=com", :bind_dn=>"joe@example2.com", :bind_pwd=>"smartvm1"}]])

rpm -qa | grep cfme
cfme-lib-5.4.0.5-1.el6cf.x86_64
mingw32-cfme-host-5.3.4.2-1.el6cf.x86_64
cfme-gemset-5.4.0.5-1.el6cf.x86_64
cfme-5.4.0.5-1.el6cf.x86_64
cfme-appliance-5.4.0.5-1.el6cf.x86_64

attached is a screen shot of the configuration. 

Password being logged in clear text is for the Trusted forest AD example2.com
Comment 4 Josh Carter 2015-07-21 15:07:48 EDT
Created attachment 1054498 [details]
config
Comment 6 CFME Bot 2015-08-23 10:50:23 EDT
New commit detected on manageiq/master:
https://github.com/ManageIQ/manageiq/commit/b597127dc95e71032c694f22fccf66a973a35944

commit b597127dc95e71032c694f22fccf66a973a35944
Author:     Alberto Bellotti <abellott@redhat.com>
AuthorDate: Tue Aug 18 09:40:50 2015 -0400
Commit:     Alberto Bellotti <abellott@redhat.com>
CommitDate: Wed Aug 19 19:01:45 2015 -0400

    Fixes issue where password are logged with Audit events.
    
    When updating Trusted forest, the bind_pwd gets logged in clear text.
    The faulty logic was in build_audit_msg, where config data of array
    type wasn't being traversed.  Leveraging the Rails ParameterFilter
    to do the magic for us.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1174458

 app/controllers/application_controller.rb | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)
Comment 7 CFME Bot 2015-08-23 10:50:27 EDT
New commit detected on manageiq/master:
https://github.com/ManageIQ/manageiq/commit/d3102243c938968bb8332ef0101621af904d412a

commit d3102243c938968bb8332ef0101621af904d412a
Author:     Alberto Bellotti <abellott@redhat.com>
AuthorDate: Fri Aug 21 16:51:14 2015 -0400
Commit:     Alberto Bellotti <abellott@redhat.com>
CommitDate: Fri Aug 21 16:52:26 2015 -0400

    PR Review Update
    
    Adding rspec for testing password filtering in config arrays.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1174458

 spec/controllers/application_controller/build_audit_spec.rb | 9 +++++++++
 1 file changed, 9 insertions(+)
Comment 8 Milan Falešník 2015-09-11 10:25:58 EDT
Checked in the upstream appliance 2015-08-31

Excerpt from the log:
[----] I, [2015-09-11T10:24:20.300659 #2884:f3398c]  INFO -- : <AuditSuccess> MIQ(Common.settings_update_save) userid: [admin] - VMDB config updated (basedn:[] to [XXXXXXXX], bind_dn:[] to [XXXXXXXX], bind_pwd:[*] to [*], ldaphost:[[]] to [["XXXXXXXXXX"]], mode:[database] to [ldap], user_suffix:[] to [XXXXXXXXXX], ldap_role:[false] to [true], user_proxies:[[{}]] to [[{:ldaphost=>"asdfadsf", :ldapport=>"389", :basedn=>"ssd", :bind_dn=>"asdf", :bind_pwd=>"[FILTERED]"}]])
Comment 11 errata-xmlrpc 2015-12-08 08:01:44 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2015:2551

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