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.

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.

An authentication bypass vulnerability has been identified in Foreman when deployed with Gunicorn versions prior to 22.0, due to the puppet-foreman configuration. This issue arises from Apache's modproxy not properly unsetting headers because of restrictions on underscores in HTTP headers, allowing authentication through a malformed header. This flaw impacts all active Satellite deployments (6.13, 6.14 and 6.15) which are using Pulpcore version 4.0+ and could potentially enable unauthorized users to gain administrative access.

In Foreman it was discovered that the delete compute resource operation, when executed from the Foreman API, leads to the disclosure of the plaintext password or token for the affected compute resource. A malicious user with the "deletecomputeresource" permission can use this flaw to take control over compute resources managed by foreman. Versions before 1.20.3, 1.21.1, 1.22.0 are vulnerable.

An issue in templates related to loader macros which were introduced together with report templates. These allow an authenticated user having permission to view any of the resources which have loader macros and permissions to view and create (probably) any kind of templates that allows this user to read any field from Foreman's database by passing in strings to the loader macros and remapping fields from the result to the original object class.

Refer: https://github.com/theforeman/foreman/blob/da504c8a2599b325853066b5099493e0c

A command injection vulnerability was identified in Foreman, affecting the "Host Init Config" template. The issue arises when commands are injected through the "Install Packages" field on the "Register Host" page. An attacker with elevated privileges on the Foreman server could craft malicious commands, which would be executed when the host is registered. This could lead to unauthorized actions.

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.

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.

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.

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.

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.

The (1) power and (2) ipmiboot actions in the HostController in Foreman before 1.2.2 allow remote attackers to cause a denial of service (memory consumption) via unspecified input that is converted to a symbol.

Ramon de C Valle (rcvalle) reports:

There is a mass assignment vulnerability in the create method of the UsersController controller.

The create method in app/controllers/userscontroller.rb deletes the user-controlled user[admin] parameter from the params hash but saves it to a local variable and assigns it to the newly created user object bypassing the :attrprotected mechanism.

def create admin = params[:user].delete :admin @user = User.new(params[:user]){|u| u.admin = admin } if @user.save @user.roles << Role.findbyname("Anonymous") unless @user.roles.map(&:name).include? "Anonymous" processsuccess else processerror end end

Any non-admin user with permissions to create other (non-admin) users (i.e. with Manager role) can create arbitrary admin users by sending a specially-crafted POST request.

Eval injection vulnerability in the create method in the Bookmarks controller in Foreman before 1.2.0-RC2 allows remote authenticated users with permissions to create bookmarks to execute arbitrary code via a controller name attribute.

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.

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.

A cross-site scripting (XSS) flaw was reported in Foreman's template preview screen. If a user were tricked into viewing a malicious template, it would lead to cross-site scripting attacks. Note that templates are commonly shared among users.

This issue was reported in version 1.6.0; however, older versions may also be vulnerable.

Upstream fix:

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

References:

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

It was found [1] that Red Hat Satellite 6 WebUI has a bug which allows an authenticated user to perform an XSS attack.

[1]: https://bugzilla.redhat.com/showbug.cgi?id=1106417

bug 1088315

Users can create malicious key names containing script tags. They are executed by other users via the autocomplete function when searching for keys.

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

Foreman has improper input validation which could lead to partial Denial of Service

A stored XSS vulnerability was found in smart class parameters and variables that are displayed on the edit pages for hosts and groups. The values for fields can be set by any userwith granted permission to edit those parameters or variables. These fields can store any value which is shown unescaped on the edit pages, leading to a stored XSS vulnerability.

Upstream bug:

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

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

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

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

Foreman before 1.8.1 does not set the secure flag for the sessionid cookie in an https session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an http session.

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.

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 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.