Reviewed: https://reviews.mahara.org/6644 Committed: https://git.mahara.org/mahara/mahara/commit/13a1712f4fd1a4eccfd54454e3449ca249d8dd89 Submitter: Robert Lyon (robe...@catalyst.net.nz) Branch: 16.04_STABLE
commit 13a1712f4fd1a4eccfd54454e3449ca249d8dd89 Author: Aaron Wells <aar...@catalyst.net.nz> Date: Tue Jun 14 19:18:40 2016 +1200 Bug 1592276: External RSS feed can be used to probe network behatnotneeded Change-Id: I635bf6d685c79b26c24805efa0a63c79df6f6201 (cherry picked from commit a6722cd94f01e55ed16efe724c56033fbb4173b0) -- 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