Bug 1174458 - Trusted Forest bind_pwd is logged in clear text
Summary: Trusted Forest bind_pwd is logged in clear text
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.3.0
Hardware: All
OS: All
low
medium
Target Milestone: GA
: 5.5.0
Assignee: abellott
QA Contact: Kyrylo Zvyagintsev
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-15 21:22 UTC by Josh Carter
Modified: 2019-04-16 14:28 UTC (History)
8 users (show)

(edit)
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.
Clone Of:
(edit)
Last Closed: 2015-12-08 13:01:44 UTC


Attachments (Terms of Use)
config (92.51 KB, image/png)
2015-07-21 19:07 UTC, Josh Carter
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2551 normal SHIPPED_LIVE Moderate: CFME 5.5.0 bug fixes and enhancement update 2015-12-08 17:58:09 UTC

Description Josh Carter 2014-12-15 21:22:34 UTC
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 21:23:17 UTC
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 19:07:22 UTC
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 19:07:48 UTC
Created attachment 1054498 [details]
config

Comment 6 CFME Bot 2015-08-23 14:50:23 UTC
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 14:50:27 UTC
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 14:25:58 UTC
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 13:01:44 UTC
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.