** Also affects: mahara/15.04 Importance: Undecided Status: New ** Also affects: mahara/16.04 Importance: Undecided Status: New
** Also affects: mahara/15.10 Importance: Undecided Status: New ** Changed in: mahara/15.04 Milestone: None => 15.04.8 ** Changed in: mahara/15.10 Milestone: None => 15.10.4 ** Changed in: mahara/16.04 Milestone: None => 16.04.2 ** Changed in: mahara/15.04 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/15.10 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/16.04 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/15.04 Importance: Undecided => Medium ** Changed in: mahara/15.10 Importance: Undecided => Medium ** Changed in: mahara/16.04 Importance: Undecided => Medium ** Changed in: mahara Status: Confirmed => Fix Committed ** Changed in: mahara/15.04 Status: New => In Progress ** Changed in: mahara/15.10 Status: New => In Progress ** Changed in: mahara/16.04 Status: New => In Progress -- 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: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress 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