mahara-contributors team mailing list archive

[Mahara Bot <1592276@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://reviews.mahara.org/6599
Committed: https://git.mahara.org/mahara/mahara/commit/a6722cd94f01e55ed16efe724c56033fbb4173b0
Submitter: Son Nguyen (son.nguyen@xxxxxxxxxxxxxxx)
Branch:    master

commit a6722cd94f01e55ed16efe724c56033fbb4173b0
Author: Aaron Wells <aaronw@xxxxxxxxxxxxxxx>
Date:   Tue Jun 14 19:18:40 2016 +1200

Bug 1592276: External RSS feed can be used to probe network

behatnotneeded
Change-Id: I635bf6d685c79b26c24805efa0a63c79df6f6201

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1592276

Title:
  Still SSRF vulnerability in external feed

Status in Mahara:
  Confirmed

Bug description:
  While taking another look at Bug 1397736 (SafeCURL) and Bug 1394820
  (SSRF in external feed) I realized there are some problems with the
  patch https://reviews.mahara.org/4029 that I filed for the SSRF bug.

  As a refresher here, the idea is that an attacker can do this:

  1. Log in to Mahara
  2. Create a page
  3. Put an "External Feed" block on the page
  4. Set the "Feed location" to "localhost:389"

  Expected result: This meaningless URL does nothing, and the block
  config harmlessly errors out and asks them for a valid URL.

  Actual result: They see an error message that tells them whether the
  web server has port 389 (unencrypted LDAP) open or not. If the error
  they see ends with "Recv failure: Connection reset by peer", they know
  the web server has a process listening on 389. If they see "Failed to
  connect to... Connection refused" they know it is not.

  It's called an SSRF (Server Side Request Forgery) attack (
  http://www.acunetix.com/blog/articles/server-side-request-forgery-
  vulnerability/ ). As Hugh pointed out on that bug, the biggest problem
  with this vulnerability is that a user can use it to scan the network
  the web server is on, checking for machine names, IP addresses, and
  port numbers.

  My patch 4029 was to add the "CURLOPT_PROTOCOLS" option to our Curl
  requests. This has the main effect of preventing an attacker from
  using an HTTP redirect to make Curl send a request to a non-HTTP
  protocol. But it doesn't at all mitigate all the information-gathering
  attacks, because it only limits the protocol section of the URL (i.e.
  "https://";) and the structure of the request Curl makes. Crucially, it
  does not limit the port of the URL, you can still enter
  "http://localhost:389";.

  As such, it didn't mitigate any of those information-gathering
  attacks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1592276/+subscriptions