larry campbell reports via the foreman bug tracker:
This was found on Foreman 1.9.0:
I came across this issue by chance. I was forced to change my Active Directory password today. After doing so, I then (mistakenly) attempted to log onto Foreman with my previous password and was able to successfully log in. The new password also worked. I tried with other browsers and even another workstation that I had never logged onto and all attempts allowed me to log on with my non-valid previous password. Perhaps something on foreman/passenger/ruby/etc is caching my credential and not re-checking?
Initial Setup: Have an Active Directory enviornment available for LDAP Authentication. Setup LDAP Authentication Source in Foreman and have a test user account created in Active Directory.
Steps to recreate: 1. Log on to Foreman with the Active Directory user. This should succeed. Log off. 2. Change your Active Directory account's password. 3. Log on to Foreman with the Active Directory user, and use the previous password. This should fail with authentication denied method, however it succeeds.
Upstream references: http://projects.theforeman.org/issues/11471
A vulnerability allowing XSS in Foreman 1.7.0 and higher was reported from upstream. It is allowed to store the key/value parameters globally or assigned to various objects and using a tickbox in the UI the values can be hidden to mask them from casual viewing. The tickbox that hides/shows the value fails to handle HTML properly and so is vulnerable to an XSS issue where HTML can be stored in a parameter, and executed by another user if they later tick the hide/show box.
Upstream bug:
http://projects.theforeman.org/issues/11859
Dominic Cleal of the Red Hat Satellite Team reports:
Reports (from tools such as Puppet) are stored in Foreman and associated to the host they came from. Users can be granted permissions to view and/or destroy reports, and also separate permissions to view certain hosts. The UI and API only list reports where the user has permission to view both reports and the host it was from.
The security issue is that both the show and destroy actions for viewing and deleting individual reports do not limit access to the hosts that the user has permission to view. A user with permission to view or destroy reports can do so for any host if they know the ID, or can easily view the last report for a given host.
External Reference: http://projects.theforeman.org/issues/11579