Mahara

user supplied $_SERVER['HTTP_HOST'] can be used for injections

Bug #1175446 reported by Hugh Davenport
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mahara
Fix Released
Low
Aaron Wells
Mahara 1.8.0
1.6
Fix Released
Low
Aaron Wells
Mahara 1.6.7
1.7
Fix Released
Low
Aaron Wells
Mahara 1.7.3
mahara (Debian)
Fix Released
Unknown

Bug Description

http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html

curl -H "host:cow\"onerror='alert(1)" localhost/code/mahara/htdocs/admin/ | fgrep cow
on a fresh install (not installed yet, as first page hit of installed will store it in db), will show some unescaped

that is used in init.php, to set wwwroot, and noreplyaddress

there is also a possible injection using lib/web.php, the get_requested_host_name uses it, which is used by clean_urls, and by AccessDeniedException

CVE References

Revision history for this message
Hugh Davenport (hugh-davenport) wrote :

also, according to http://www.ietf.org/rfc/rfc2616.txt s 5.2, "If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored."
see http://stackoverflow.com/a/2297421

Revision history for this message
Aaron Wells (u-aaronw) wrote :

(master)aaronw@vegas:~/www/moodle2$ curl -H "host:cow\"onerror='alert(1)" vegas.wgtn.cat-it.co.nz/mahara/htdocs
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://cow&quot;onerror='alert(1)/mahara/htdocs/">here</a>.</p>
<hr>
<address>Apache/2.2.20 (Ubuntu) Server at cow&quot;onerror='alert(1) Port 80</address>
</body></html>

Aaron Wells (u-aaronw)
Changed in mahara:
importance: Undecided → Low
Revision history for this message
Aaron Wells (u-aaronw) wrote :

The attacks on $cfg->wwwroot and $cfg->noreplyaddress are only possible by sending across a specially tailored HTTP request at just the right time during the installation process. So, I'm going to call them a non-issue. Very paranoid admins can guard against these by providing a $cfg->wwwroot and $cfg->noreplyaddress directly in their config.php, but I don't think we need to remove the automatic setting of it for lazy admins.

Regarding the lib/web.php part, I see where $_SERVER['HTTP_HOST'] is used by get_requested_host_name(). But that function is only used two places:

1. In get_full_script_path(), which is then used by AccessDeniedException()
2. In smarty(), where, if and only if $cfg->cleanurluserssubdomains is turned on, it is used to create a "fake wwwroot" for Javascript to come from.

Both of these seem to be related to Richard Mansfield's changes in May 2012 to allow for clean url user subdomains, i.e. making the clean URL for a user's address be https://aaronw.mahara.org . Perhaps we could strengthen this by changing get_requested_host_name() so that it runs $_SERVER['HTTP_HOST'] through a regular expression that makes sure it only matches a valid domain-name-compatible hostname, e.g. [a-z0-9]{2}|[a-z0-9][a-z0-9-]*[a-z0-9](\.[a-z0-9]{2}|[a-z0-9][a-z0-9-]*[a-z0-9])* .

Revision history for this message
Aaron Wells (u-aaronw) wrote :

To replicate the issue with get_requested_host_name():

1. Install Mahara
2. Find a user ID that doesn't exist yet (like ID 10 on a brand new installation with less than 10 users)
3. On the command line: curl -H "host:cow\"onerror='alert(1)'" -i "http://vegas.wgtn.cat-it.co.nz/mahara/htdocs/user/view.php?id=10"

You'll receive an HTTP 303 See Other response header, and the Location: line will include your arbitrary host string. I can't see how this is directly exploitable... but it could potentially be a building block of some sort for another attack.

Revision history for this message
Aaron Wells (u-aaronw) wrote :

https://reviews.mahara.org/2443

Changed in mahara:
status: New → In Progress
assignee: nobody → Aaron Wells (u-aaronw)
Revision history for this message
Robert Lyon (robertl-9) wrote :

with clean urls and clean url subdomains set to true

I noted through testing that if in function get_requested_host_name()

If I commented out the $_SERVER and $_ENV checks so that I was only dealing with the part

    if (false === $hostname && !empty($CFG->wwwroot)) {

    }

If I set added a bad wwwroot eg.
  $CFG->wwwroot = 'htpp://www.fis^h.com?bitofatest';
before it

I would get the error as expected when navigating around site but I'd also get the links to css files using the bad url.

Would this be a problem? or is my test too manually invasive to be a 'real world' problem?

Revision history for this message
Aaron Wells (u-aaronw) wrote :

Yeah, I don't think we can too much about attacks that alter the contents of the config.php, and still less about attacks that alter the source code of other files. We mostly need to focus on attacks that are carried out via the HTTP inputs to the web server.

Aaron Wells (u-aaronw)
Changed in mahara:
milestone: none → 1.8.0rc1
status: In Progress → Fix Committed
Revision history for this message
Aaron Wells (u-aaronw) wrote :

Backporting:

1.6: https://reviews.mahara.org/2523
1.7: https://reviews.mahara.org/2524

information type: Private Security → Public Security
information type: Public Security → Private Security
Aaron Wells (u-aaronw)
Changed in mahara:
milestone: 1.8rc1 → 1.8.0
Aaron Wells (u-aaronw)
information type: Private Security → Public Security
Aaron Wells (u-aaronw)
Changed in mahara:
status: Fix Committed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in mahara (Debian):
status: Unknown → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in mahara (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.