Eval injection vulnerability in tftpapi.rb in the TFTP module in the Smart-Proxy in Foreman before 1.10.4 and 1.11.x before 1.11.2 allows remote attackers to execute arbitrary code via the PXE template type portion of the PATHINFO to tftp/.

A flaw was found in the Foreman project. The Proxmox compute resource exposes the password through the API to an authenticated local attacker with viewhosts permission. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability. Versions before foremanfogproxmox 0.13.1 are affected

The Smart-Proxy in Foreman before 1.4.5 and 1.5.x before 1.5.1 allows remote attackers to execute arbitrary commands via shell metacharacters in the path parameter to tftp/fetchbootfile.

Local file inclusion in FHEM 6.0 allows in fhem/FileLoglogWrapper file parameter can allow an attacker to include a file, which can lead to sensitive information disclosure.

Summary: A privilege escalation flaw was found in Foreman. The Usergroup model does not validate role assignments against the calling user's permissions, unlike the User model which enforces escalation checks. This flaw allows an authenticated user with usergroup management permissions to attach arbitrary roles, including administrative roles, to a user group and add themselves as a member, resulting in full privilege escalation to administrator-level access.

Requirements to exploit: Authenticated Foreman account with createusergroups or editusergroups permission (e.g., Site manager, Organization admin, Manager roles, or any custom role including these permissions). Attacker crafts a single API request to create or update a user group with a privileged roleid and their own userid.

Dominic Cleal of Red Hat reported the below issue in Foreman:

A user with the editusers permission (e.g. with the Manager role) is allowed to edit admin users. This allows them to change the password of the admin user's account and gain access to it.

Upstream bug: http://projects.theforeman.org/issues/10829 Upstream fix: pull request not yet merged, see upstream bug

A user who has no roles or permissions can still view task's details both through the web UI and through api, if the user knows the UUID of the task.

This was introduced in foreman-tasks@79a0e2cb5, before this commit tasks were looked up through findresource which performed authorization checks. After this change, permissions are bypassed.

Upstream Commit:

https://github.com/theforeman/foreman-tasks/pull/151/commits/79a0e2cb52fbf872863a3a176e5b1d9a09fc984d

Cross-site scripting (XSS) vulnerability in intervalCheck.jsp in Coremail XT 3.0 allows remote attackers to inject arbitrary web script or HTML via the sid parameter.

Cross-site scripting (XSS) vulnerability in Coremail XT3.0 allows remote attackers to inject arbitrary web script or HTML via a hyperlink in a document attachment.

A flaw has been found in foreman when HTTP parameters are modified in httpproxiescontroller and httpproxy files. Attackers can perform an SSRF attack and steal cloud metadata service on AWS/GCP/Azure environment through foreman component.

Cross-site scripting (XSS) vulnerability in Foreman before 1.4.5 and 1.5.x before 1.5.1 allows remote attackers to inject arbitrary web script or HTML via the Name field to the New Host groups page, related to create, update, and destroy notification boxes.

Multiple cross-site scripting (XSS) vulnerabilities in the host YAML view in Foreman before 1.4.5 and 1.5.x before 1.5.1 allow remote attackers to inject arbitrary web script or HTML via a parameter (1) name or (2) value related to the host.

Directory traversal vulnerability in Dan Costin File Transfer before 1.2f allows remote attackers to read arbitrary files via a "..\" (dot dot backslash) in the filename.

Marek Hulán of Red Hat reports:

User can define a job template and specify input name containing JS code. When someone tries to invoke such job, the form is generated based on this name without proper escaping so the JS gets executed.

Upstream issue:

http://projects.theforeman.org/issues/16019

Proposed upstream patch:

https://github.com/theforeman/foreman/pull/3715/commits/4b63d2c7cdad76ed2bf96d9f8dff7e0c5cdabda6

Marek Hulán of Red Hat reports:

When accessing Foreman as a user limited to specific organization, having access to other organization IDs and having unlimited filters could allow a user to access/modify other organization data by using the organization ID as an API parameter.

Upstream bug:

http://projects.theforeman.org/issues/15182

Upstream patch:

https://github.com/theforeman/foreman/pull/3553/commits/42066cfa19de316449954079c07bdf1e4cc5eb0a

A flaw has been found in foreman when HTTP parameters are modified in httpproxiescontroller and httpproxy files. Attackers can perform an SSRF attack and steal cloud metadata service on AWS/GCP/Azure environment through foreman component.

Jeremy Choi and Keqin Hong of the Red Hat HSS Pen-Test Team reported a stored XSS issue in foreman. Authenticated users who are able to add bookmarks may inject malicious javascript or html that will be executed by other users viewing the page.

Ohad Levy of Red Hat reports:

since 1e0fd283 it is possible to override spoof by providing a hostname parameters.

this would allow to retrieve any template of any host bypassing authentication.

External references: http://projects.theforeman.org/issues/5436 http://projects.theforeman.org/projects/foreman/repository/revisions/1e0fd283180dc6bda30c880898cdea69cb579194

Fixed in: https://github.com/theforeman/foreman/pull/1404 https://github.com/theforeman/foreman/commit/aa0ebe8

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

Dominic Cleal of Red Hat reports:

The "requiressl" setting (in /etc/foreman/settings.yml) should enforce that web requests sent to Foreman over HTTP are redirected to HTTPS, but this was found not to happen with API requests (e.g. from Hammer CLI). Foreman will process API requests over HTTP, but should have redirected.

Redirection won't help with credentials having already been sent, but should give some notification that the user/app is using the wrong URL.

Affects all versions of Foreman since 1.1.

The issue has already been fixed since Foreman 1.9.0-RC1 via a refactor in #10471.

To mitigate this with Apache, add a stanza to the HTTP VirtualHost (e.g. in /etc/httpd/conf.d/05-foreman.d/apiredirect.conf) similar to:

RewriteEngine On RewriteRule ^/api/(.) https://%{SERVERNAME}/api/$1 [R,L]

External reference:

http://projects.theforeman.org/issues/11119

An attacker with elevated privileges can utilize Ansible functions to carry out actions as the Foreman-proxy user on the system. The prerequisite for this is that the hosts must have already been added to Foreman, and the attacker must have access to one of these hosts. If the attacker already has access to the system, they are deemed trustworthy with a high level of privilege.

fuse 2.8.5 and earlier does not properly handle when /etc/mtab cannot be updated, which allows local users to unmount arbitrary directories via a symlink attack.

Certain legacy functionality in fusermount in fuse 2.8.5 and earlier, when util-linux does not support the --no-canonicalize option, allows local users to bypass intended access restrictions and unmount arbitrary directories via a symlink attack.

fusermount in fuse 2.8.5 and earlier does not perform a chdir to / before performing a mount or umount, which allows local users to unmount arbitrary directories via unspecified vectors.

Dominic Cleal of Red Hat reports:

Users who are logged in with permissions to view some hosts are able to preview provisioning templates for any host by specifying its hostname in the URL, as the specific viewhosts permissions and filters aren't checked. If the organization or location features are enabled, the user will still be restricted to their associated orgs/locs.

This can disclose configuration information about the host, including root password hashes if used in preseed/kickstart templates.

Upstream bug:

http://projects.theforeman.org/issues/15490

Proposed patch:

https://github.com/theforeman/foreman/pull/2428

Brad Buckingham of Red Hat reports:

After settings a new role to allow restricted access on a repository with a filter (filter set on the Product Name), the filter is not respected when the actions are done via hammer using the repository id.

External reference: http://projects.theforeman.org/issues/18838