Red Hat CloudForms 4.6

transport.py in the SSH server implementation of Paramiko before 1.17.6, 1.18.x before 1.18.5, 2.0.x before 2.0.8, 2.1.x before 2.1.5, 2.2.x before 2.2.3, 2.3.x before 2.3.2, and 2.4.x before 2.4.1 does not properly check whether authentication is completed before processing other requests, as demonstrated by channel-open. A customized SSH client can simply skip the authentication step.

rubyzip gem rubyzip version 1.2.1 and earlier contains a Directory Traversal vulnerability in Zip::File component that can result in write arbitrary files to the filesystem. This attack appear to be exploitable via If a site allows uploading of .zip files , an attacker can upload a malicious file that contains symlinks or files with absolute pathnames "../" to write arbitrary files to the filesystem..

A flaw was found in the way Postgresql allowed a user to modify the behavior of a query for other users. An attacker with a user account could use this flaw to execute code with the permissions of superuser in the database. Versions 9.3 through 10 are affected.

Ansible Tower through version 3.2.3 has a vulnerability that allows users only with access to define variables for a job template to execute arbitrary code on the Tower server.

There is a possible denial of service vulnerability in Action View (Rails) <5.2.2.1, <5.1.6.2, <5.0.7.2, <4.2.11.1 where specially crafted accept headers can cause action view to consume 100% cpu and make the server unresponsive.

CloudForms Management Engine (cfme) is vulnerable to an improper security setting in the dRuby component of CloudForms. An attacker with access to an unprivileged local shell could use this flaw to execute commands as a high privileged user.

There is a File Content Disclosure vulnerability in Action View <5.2.2.1, <5.1.6.2, <5.0.7.2, <4.2.11.1 and v3 where specially crafted accept headers can cause contents of arbitrary files on the target system's filesystem to be exposed.

There is an information leak vulnerability in Sprockets. Versions Affected: 4.0.0.beta7 and lower, 3.7.1 and lower, 2.12.4 and lower. Specially crafted requests can be used to access files that exists on the filesystem that is outside an application's root directory, when the Sprockets server is used in production. All users running an affected release should either upgrade or use one of the work arounds immediately.

A Broken Access Control vulnerability in Active Job versions >= 4.2.0 allows an attacker to craft user input which can cause Active Job to deserialize it using GlobalId and give them access to information that they should not have. This vulnerability has been fixed in versions 4.2.11, 5.0.7.1, 5.1.6.1, and 5.2.1.1.

Ansible Tower before version 3.2.4 has a flaw in the management of system and organization administrators that allows for privilege escalation. System administrators that are members of organizations can have their passwords reset by organization administrators, allowing organization administrators access to the entire system.

In postgresql 9.3.x before 9.3.21, 9.4.x before 9.4.16, 9.5.x before 9.5.11, 9.6.x before 9.6.7 and 10.x before 10.2, pg_upgrade creates file in current working directory containing the output of `pg_dumpall -g` under umask which was in effect when the user invoked pg_upgrade, and not under 0077 which is normally used for other temporary files. This can allow an authenticated attacker to read or modify the one file, which may contain encrypted or unencrypted database passwords. The attack is infeasible if a directory mode blocks the attacker searching the current working directory or if the prevailing umask blocks the attacker opening the file.

CloudForms Management Engine (cfme) before 5.7.3 and 5.8.x before 5.8.1 lacks RBAC controls on certain methods in the rails application portion of CloudForms. An attacker with access could use a variety of methods within the rails application portion of CloudForms to escalate privileges.

Sinatra before 2.0.2 has XSS via the 400 Bad Request page that occurs upon a params parser exception.

Ansible 2.5 prior to 2.5.5, and 2.4 prior to 2.4.5, do not honor the no_log task flag for failed tasks. When the no_log flag has been used to protect sensitive data passed to a task from being logged, and that task does not run successfully, Ansible will expose sensitive data in log files and on the terminal of the user running Ansible.