CVE-2015-5233 - reports show/destroy not restricted by host authorization
|Assigned To:||Daniel Lobato Garcia|
|Found in release:||1.5.0||Pull request:||https://github.com/theforeman/foreman/pull/2644|
|Velocity based estimate||-|
Foreman 1.5.0 or higher are vulnerable to an authorization issue that allows users to view and delete reports for hosts that they don't have access to.
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.
Thanks to Daniel Lobato Garcia of Red Hat for reporting this to firstname.lastname@example.org.
Fixes #11579 - Reports show/destroy restricted by host authorization (CVE-2015-5233)
ReportsController 'show' and 'destroy' now perform a check to see if
the User is authorized to see the Host associated with the Report. In
case it's not, it returns 404, as to not give hints whether a Report
ID or Host ID are valid.
I followed the same approach on the API controllers. 'last' was not
vulnerable due to using my_reports which performs the necessary
check on 'view_hosts' permission.
#1 Updated by Dominic Cleal almost 2 years ago
- Found in release set to 1.5.0
It looks like this extends to both the regular #show and #destroy behaviour on the UI and API controllers, which would allow somebody with *_reports permission but not the associated host to view or destroy a report.
I think the vulnerable locations are:
1. ReportsController#show, #destroy - allowing viewing and deletion of reports for users with the appropriate *_reports permission but not the appropriate view_hosts permission. (Not just "last".)
2. API ReportsController#show, #destroy - ditto, but I think the #last method is safe as it uses Report.my_reports.
The authorisation here is complex and two-fold, as it's both using .authorized and .my_reports to limit based on both reports and host permissions (inc taxonomies).