The deployment script in the unsupported "OpenShift Extras" set of add-on scripts, in Red Hat Openshift 1, installs a default public key in the root user's authorizedkeys file.

In Red Hat Openshift 1, weak default permissions are applied to the /etc/openshift/serverpriv.pem file on the broker server, which could allow users with local access to the broker to read this file.

RubyGems passenger 4.0.0 betas 1 and 2 allows remote attackers to delete arbitrary files during the startup process.

Michael Scherer (mscherer) reports:

the file https://github.com/openshift/origin-server/blob/master/node-util/www/html/restorer.php used to restore application after being idle fails to safely handle user supplied data that is later used on the command line.

Michael Scherer (mscherer) reports:

the file https://github.com/openshift/origin-server/blob/master/node-util/www/html/restorer.php used to restore application after being idle fails to safely handle user supplied data that is later used in the HTTP headers for the Location: value which can then result in request redirection to an arbitrary page.

It is reported that the rhc-chk command when run with the -d displays the password in cleartext.

(1) oo-analytics-export and (2) oo-analytics-import in the openshift-origin-broker-util package in Red Hat OpenShift Enterprise 1 and 2 allow local users to have unspecified impact via a symlink attack on an unspecified file in /tmp.

Michael Scherer reported that the passenger ruby gem, when used in standalone mode, does not use temporary files in a secure manner. In the lib/phusionpassenger/standalone/main.rb's createnginxcontroller function, passenger creates an nginx configuration file insecurely and starts nginx with that configuration file:

@tempdir = "/tmp/passenger-standalone.#{$$}" @configfilename = "#{@tempdir}/config"

If a local attacker were able to create a temporary directory that passenger uses and supply a custom nginx configuration file they could start an nginx instance with their own configuration file. This could result in a denial of service condition for a legitimate service or, if passenger were executed as root (in order to have nginx listen on port 80, for instance), this could lead to a local root compromise.

OpenShift cartridge allows remote URL retrieval

Clayton Coleman reports:

Never use the form in ruby when the variables aren't known to be safe values

def self.downloadfromurl(url) maxdltime = (Rails.application.config.downloadedcartridges[:maxdownloadtime] rescue 10) || 10 maxfilesize = (Rails.application.config.downloadedcartridges[:maxcartsize] rescue 20480) || 20480 maxredirs = (Rails.application.config.downloadedcartridges[:maxdownloadredirects] rescue 2) || 2 curl --max-time #{maxdltime} --connect-timeout 2 --location --max-redirs #{maxredirs} --max-filesize #{maxfilesize} -k #{url} end

If 'URL' is not properly validated, then someone could inject " ; rm -rf /"

In this method, URL needs to be a properly formatted URI with a known whitelist of parameters.

In addition, we should only accept URI's that are of the following whitelisted criteria:

Parses URI successfully Protocol is 'http', 'https', 'git', 'ftp' (I can't think of others that are really safe). 'file' should NOT be allowed Host must be specified, and be non localhost (otherwise you allow a local injection attack). We need to be very careful here not to allow probing of the internal network, so we should only allow addresses that resolve outside of the exsrvs. Port should be valid Path should be valid

If the URI does not meet these criteria an error message should be returned to the user.

Michael Scherer (misc) of Red Hat reports:

Looking at a recent git checkout of openshift, I found that some script use a hardcoded or easy to guess filename in /tmp, in this case : https://github.com/openshift/origin-server/blob/master/port-proxy/bin/openshift-port-proxy-cfg#L13

I am not sure this can be exploited, but after searching a while, here is a credible attack.

This filename is used on https://github.com/openshift/origin-server/blob/master/port-proxy/bin/openshift-port-proxy-cfg#L144

While it took me a while to figure what the code of lockwrap does exactly, I found out there is a small windows of time between "we check the file exist and is empty" and "we write 0 or a return code to the file".

Let's imagine the following scenario, some attacker has shell access to the server that run this ( ie, a openshift node if I am not wrong ). People have access to the node, at least on openshift-online and this is required to push with git the code ( unless setup otherwise ).

This attacker create 5000 empty files who match the pattern /tmp/openshift-port-proxy-reload.req.????? ( and this could be something else than numbers, like .aaaaa ). Then he wait, and 1 second after, erase it and replace it by a link to another arbitrary file. Doing it with the 5000 files and a proper timing ( like waiting 1/5000 second between each file operation ) would make sure that if a operation check a file and then 1 second later, write to the file, this would not be the same for at least 1 of them. ( at least, that's my understanding, timing may be harder to get right on a real computer with enough ram, cpu and fast disk than the one I imagined ). Another variant would be to use something that is triggered when stat is run, but inotify cannot be used, and audit subsystem requires root.

Then, if someone else run the script and enter the function lockwrap that reload the proxy, it would first do a stat to check the file is empty (https://github.com/openshift/origin-server/blob/master/port-proxy/bin/openshift-port-proxy-cfg#L152) then reload the proxy ( and check all others file with stat before ), and there is a non negligeable chance that the script would write the return code in a different file ( ie, if that's a link, write it somewhere else ), since it write on all files matching the pattern, and not only the one created by mkstemp.

Depending on the kernel configuration and installation, this can be mitigated ( openshift online use polyinstanciation of /tmp, for example, newer kernel ship the yama module, for another example ). But in the most favourable case for the attacker ( ie no protection ), this mean he can create a file in a arbitray location with a content of 0 or 1.

The script is executed as root , as part as the user creation : https://github.com/openshift/origin-server/blob/master/node/lib/openshift-origin-node/model/unixuser.rb#L87 , function create, just after running useradd command ( hence the assumption this is run as root )

that function call initializeopenshiftportproxy https://github.com/openshift/origin-server/blob/master/node/lib/openshift-origin-node/model/unixuser.rb#L139

that run the command "openshift-port-proxy-cfg setproxy" https://github.com/openshift/origin-server/blob/master/node/lib/openshift-origin-node/model/unixuser.rb#L583

that then that script run the function lockwrap : https://github.com/openshift/origin-server/blob/master/port-proxy/bin/openshift-port-proxy-cfg#L263

and then lockwrap trigger the problem described before.

So a attacker could just create and remove several application until the attack succeed, ie, bruteforce it and make a 0 or 1 be written in a arbitrary location as root ( if selinux, polyinstanciation etc are disabled ).

openshift-origin-port-proxy is part of the entreprise release version 1, IIRC, of F18 and rawhide.

So I think this will requires a errata and a CVE if I am not wrong on my analysis of the problem. The issue was not discussed with anyone explicitely (I just discussed about the code on #fedora-devel on irc.freenode.net with 2 others fedora packagers but the exact issue was not disclosed ).

OpenShift haproxy cartridge: predictable /tmp in set-proxy connection hook which could facilitate DoS

mcollective has a default password set at install

Openshift has shell command injection flaws due to unsanitized data being passed into shell commands.

It was reported that watchman in openshift node-utils creates /var/run/watchman.pid and /var/log/watchman.ouput with world writable permission.