1236684 - Port banning can be bypassed with 30x redirect

Status: RESOLVED FIXED

(Firefox for iOS :: Browser, defect)

Description

[Muneaki Nishimura]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.48 Safari/537.36

Steps to reproduce:

Port banning can be bypassed with 30x redirect

Firefox for iOS has port banning feature but it can be bypassed by following two ways.

#1. Tap "Try again" or reload button on a port error screen
Navigate to a banned port of a target host e.g., http://alice.csrf.jp:143. Here port 143 is a known port of IMAP so Firefox shows a "restricted port error" screen instead. However, if you tap "Try again" button or reload icon on a error screen Firefox sends a GET request to the port and shows a response. Note that it doesn't reproduce on other major browsers on iOS e.g., Safari or Chrome.

#2. Access a restricted port on a target host through 30x redirect
Firefox allows to access banned ports when navigating to a banned port of a target host through a 30x redirector. In this case, any kinds of HTTP method can be sent to a banned port without any error screen. Note that it can reproduce on Safari but not reproduce on Chrome for iOS.




Actual results:

The following URL is a PoC of these issues.
http://mallory.csrf.jp/ios/portblock.html

The above page has two buttons. The first one is to send a POST request directly to a banned port :143 of a target host. This is for the above scenario #1. The second one is to send a same POST request through a 307 redirector placed on a attacker's domain. It is for the above scenario #2.


Expected results:

Firefox should block accessing of banned ports in any case.

Comment 1

[Daniel Veditz [:dveditz]]

The "try again" (issue #1) we can possibly do something about, but I think #2 is just iOS behavior.

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

There are two requests happening:

GET http://moo.mx/
GET http://moo.mx/favicon.ico

The second I have identified as being the SDWebImageDownloader. So this is clearly something we are originating. However, I think we can ignore this request because it only happens as a result of the first one. So the focus here should be to not let the first one happen in the first place.

The first however is interesting. This happens because from the error page, via the Try again button, we call window.location.reload(). The fact that a JavaScript reload() causes an actual page load may in fact be a WebKit bug. I think the same low port rules should apply to reload().

As a mitigation, I think we should not show the Try Again button at all in case of this error. I think a simple patch to start this would be to have a list of non-retryable errors. I don't know what that full list should look like but WebKitErrorDomain/103 "Not allowed to use restricted network port" should be the first to be on it.

(This does not happen in Safari because we simply do error handling in a different kind of way. Safari has access to more hidden APIs to better deal with it. We have to do some tricks with a JS error page.)

Comment 3

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Additional note: The effect of hitting the Reload button is the same as the Try Again button. WebKit actually loads the page. Even though it rejected it on first load. That is not because we are calling WKWebView.reload() but because our ErrorPage.html, which is what we are really reloading, does a JavaScript location.reload().

Comment 4

[Muneaki Nishimura]

This bug has been resolved by Apple as CVE-2016-1782 on iOS 9.3.
https://support.apple.com/en-us/HT206166