[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CVE-2015-7519



On 26 April 2016 at 10:27, Linus van Geuns <linus@vangeuns.name> wrote:
> On Tue, Apr 26, 2016 at 10:08 AM, Raphael Geissert <atomo64@gmail.com> wrote:
>> On 19 February 2016 at 09:35, Linus van Geuns <linus@vangeuns.name> wrote:
>>> On Thu, Feb 18, 2016 at 8:35 PM, Thorsten Alteholz <debian@alteholz.de> wrote:
>>>> On irc you wrote:
>>>> 15:05 < Nirkus> have some old redmine running on squeeze-lts (yeah..) and since the update yesterday the following redmine code bails out with "private method `split' called for nil:NilClass" at the following line:
>>>> 15:06 < Nirkus> @env['QUERY_STRING'].present? ? @env['QUERY_STRING'] : (@env['REQUEST_URI'].split('?', 2)[1] || '')
>>>>
>>>> In CVE-2015-7519[1] it was detected, that it is possible to obtain
>>>> unauthorized access if you send http variables with "_" instead of "-". More information can be found here[2]. As a solution it was proposed to simply filter out all variables containing an "_". This was already done in mod_cgi of apache[3] and now I applied a similar patch to libapache2-mod-passenger as well.
>>>>
>>>> Unfortunately there seems to be software that relies on underscores in variable names. So if you need such variables you might want to use the workaround for apache, described in[2].
>>>
>>> I am only scratching the surface of Ruby, Passenger, Rack/Rails and
>>> Redminde, so corrections and clarifications welcome. :)
>>>
>> [...]
>>>
>>> I am not sure whether REQUEST_URI and QUERY_STRING are actually passed
>>> as per-request env. variables by Passenger or added to the env hash by
>>> Rack/Rails.
>>> Still, this looks like a regression to me, since it removes previously
>>> available variables, which should not be in scope of CVE-2015-7519.
>>
>> It is a regression, there's no way for applications using
>> mod_passenger to work after the latest update. Not only did the update
>> switch to a native package and drop some documentation, but it broke
>> the module.
>>
>> Granted, the package is safer now that it doesn't work.
>
> Yeah, granted
>
> "We" are no longer affected by this regression since the affected
> Redmine instance has been migrated to a current release running on
> Debian jessie.
> So, thank you for the incentive to do the right thing.

FWIW, attached patch should do it. It can be applied on top of the
non-LTS version of passenger.

Cheers,
-- 
Raphael Geissert
Index: passenger-2.2.11debian/ext/apache2/Hooks.cpp
===================================================================
--- passenger-2.2.11debian.orig/ext/apache2/Hooks.cpp	2016-04-26 11:29:20.620915082 +0200
+++ passenger-2.2.11debian/ext/apache2/Hooks.cpp	2016-04-26 14:20:05.944237319 +0200
@@ -779,6 +779,30 @@ private:
 	char *lookupEnv(request_rec *r, const char *name) {
 		return lookupName(r->subprocess_env, name);
 	}
+
+	static bool
+	isAlphaNum(char ch) {
+		return (ch >= '0' && ch <= '9') || (ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z');
+	}
+
+	/**
+	 * For CGI, alphanum headers with optional dashes are mapped to UPP3R_CAS3. This
+	 * function can be used to reject non-alphanum/dash headers that would end up with
+	 * the same mapping (e.g. upp3r_cas3 and upp3r-cas3 would end up the same, and
+	 * potentially collide each other in the receiving application). This is
+	 * used to fix CVE-2015-7519.
+	 */
+	static bool
+	containsNonAlphaNumDash(const char *s) {
+		size_t len = strlen(s);
+		for (size_t i = 0; i < len; i++) {
+			const char start = s[i];
+			if (start != '-' && !isAlphaNum(start)) {
+				return true;
+			}
+		}
+		return false;
+	}
 	
 	void inline addHeader(apr_table_t *table, const char *name, const char *value) {
 		if (name != NULL && value != NULL) {
@@ -847,7 +871,7 @@ private:
 		hdrs_arr = apr_table_elts(r->headers_in);
 		hdrs = (apr_table_entry_t *) hdrs_arr->elts;
 		for (i = 0; i < hdrs_arr->nelts; ++i) {
-			if (hdrs[i].key) {
+			if (hdrs[i].key && !containsNonAlphaNumDash(hdrs[i].key)) {
 				addHeader(headers, http2env(r->pool, hdrs[i].key), hdrs[i].val);
 			}
 		}

Reply to: