** Changed in: mahara/15.04
Status: In Progress => Fix Committed
** Changed in: mahara/15.10
Status: In Progress => Fix Committed
** Changed in: mahara/16.04
Status: In Progress => Fix Committed
--
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:
Fix Committed
Status in Mahara 15.04 series:
Fix Committed
Status in Mahara 15.10 series:
Fix Committed
Status in Mahara 16.04 series:
Fix Committed
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
_______________________________________________
Mailing list: https://launchpad.net/~mahara-contributors
Post to : mahara-contributors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mahara-contributors
More help : https://help.launchpad.net/ListHelp
