A vulnerability was discovered in the Foreman Remote Execution feature, allowing an unauthorized remote attacker to perform arbitrary code execution on managed hosts. The issue affects the component smartproxydynflow 0.1.8 and later (Foreman >= 1.15, Satellite >= 6.3)

Introducing commit:

https://github.com/theforeman/smartproxydynflow/commit/cb7b0b5c9b602f737ab4c6e9fb47c158241cf49c#diff-6dee70f4339cfc3dd8cedfc2a34f14c2

References:

https://bugzilla.redhat.com/showbug.cgi?id=1629003

An admin user on Foreman can bypass safe mode in templates and execute arbitrary code via the Report Templates function. When changing the "template" JSON value in the POST request, an attacker can exploit the bind() call in safemode to inject an OS command in the underlying operating system.

A server side remote code execution vulnerability was found in Foreman project. A authenticated attacker could use Sendmail configuration options to overwrite the defaults and perform command injection. The highest threat from this vulnerability is to confidentiality, integrity and availability of system. Fixed releases are 2.4.1, 2.5.1, 3.0.0.

foreman-debug before version 1.15.0 is vulnerable to a flaw in foreman-debug's logging. An attacker with access to the foreman log file would be able to view passwords, allowing them to access those systems.

A flaw was found in foreman before version 1.15 in the logging of adding and registering images. An attacker with access to the foreman log file would be able to view passwords for provisioned systems in the log file, allowing them to access those systems.

A flaw was found in foreman before 1.16.1. The issue allows users with limited permissions for powering oVirt/RHV hosts on and off to discover the username and password used to connect to the compute resource.

The (1) Organization and (2) Locations APIs and UIs in Foreman before 1.11.4 and 1.12.x before 1.12.0-RC3 allow remote authenticated users to bypass organization and location restrictions and (a) read, (b) edit, or (c) delete arbitrary organizations or locations via unspecified vectors.

A credential leak vulnerability was found in Foreman through Azure Compute Profile. This flaw exposes the compute profile credentials to the all authenticated users with "viewcomputeprofiles" permission.

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

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.

A flaw was found in the Foreman project. The Datacenter plugin 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.

A cross-site scripting (XSS) flaw was found in the foreman component of satellite. An attacker with privilege to create entries using the Hosts, Monitor, Infrastructure, or Administer Menus is able to execute a XSS attacks against other users, possibly leading to malicious code execution and extraction of the anti-CSRF token of higher privileged users. Foreman before 1.18.3, 1.19.1, and 1.20.0 are vulnerable.

A disclosure of sensitive information flaw was found in foreman via the GraphQL API. If the introspection feature is enabled, it is possible for attackers to retrieve sensitive admin authentication keys which could result in a compromise of the entire product's API.

app/controllers/api/v1/hostscontroller.rb in Foreman before 1.2.2 does not properly restrict access to hosts, which allows remote attackers to access arbitrary hosts via an API request.

Multiple SQL injection vulnerabilities in app/models/concerns/hostcommon.rb in Foreman before 1.2.3 allow remote attackers to execute arbitrary SQL commands via the (1) fqdn or (2) hostgroup parameter.

Smart Proxy (aka Smart-Proxy and foreman-proxy) in Foreman before 1.5.4 and 1.6.x before 1.6.2 does not validate SSL certificates, which allows remote attackers to bypass intended authentication and execute arbitrary API requests via a request without a certificate.

Eric Helms of Red Hat reports:

Users can access resources in other organizations via the API if they can guess the name of the resource as access restrictions are not properly enforced.

A flaw was found in foreman before version 3.3. The server exposes a GraphQL API with limited access. If introspection is enabled (usually by default), it allow attackers to query a settings type without any authentication and retrieve the product settings, including the OAuth consumerkey and OAuth consumersecret properties. These elements can be used to authenticate as foremanapiadmin and gain full control of the product's REST API.

A command injection flaw was found in the "Host Init Config" template in the Foreman application via the "Install Packages" field on the "Register Host" page. This flaw allows an attacker with the necessary privileges to inject arbitrary commands into the configuration, potentially allowing unauthorized command execution during host registration. Although this issue requires user interaction to execute injected commands, it poses a significant risk if an unsuspecting user runs the generated registration script.

An input sanitization flaw was found in the id field in the dashboard controller of Foreman before 1.16.1. A user could use this flaw to perform an SQL injection attack on the back end database.

Foreman before 1.10.3 and 1.11.0 before 1.11.0-RC2 allow remote authenticated users to read, modify, or delete private bookmarks by leveraging the (1) editbookmarks or (2) destroybookmarks permission.

A flaw was found in foreman 1.5.1. The remote execution plugin runs commands on hosts over SSH from the Foreman web UI. When a job is submitted that contains HTML tags, the console output shown in the web UI does not escape the output causing any HTML or JavaScript to run in the user's browser. The output of the job is stored, making this a stored XSS vulnerability.

Cross-site scripting (XSS) vulnerability in app/helpers/formhelper.rb in Foreman before 1.12.2, as used by Remote Execution and possibly other plugins, allows remote attackers to inject arbitrary web script or HTML via the label parameter.

It was found that foreman before 1.13.0 is vulnerable to a stored XSS via an organization or location name. This could allow an attacker with privileges to set the organization or location name to display arbitrary HTML including scripting code within the web interface.

A cross-site scripting vulnerability was found in foreman in pages where facts are submitted through insertion of HTML in its name or value.

Upstream bug:

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

A vulnerability was found in foreman 1.14.0. When creating an organization or location in Foreman, if the name contains HTML then the second step of the wizard (/organizations/id/step2) will render the HTML. This occurs in the alertbox on the page. The result is a stored XSS attack if an organization/location with HTML in the name is created, then a user is linked directly to this URL.

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

An improper authorization handling flaw was found in Foreman. The OpenSCAP plugin for the smart-proxy allows foreman clients to execute actions that should be limited to the Foreman Server. This flaw allows an authenticated local attacker to access and delete limited resources and also causes a denial of service on the Foreman server. The highest threat from this vulnerability is to integrity and system availability.

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