[Original here: https://wwws.nightwatchcybersecurity.com/2016/07/26/research-crashing-browsers-remotely-via-insecure-search-suggestions/] Summary Intercepting insecure search suggestion requests from browsers, and returning very large responses leads to browser crashes (but not RCE). Affected browsers areFireFox on the desktop and Android, and Chrome on desktop and Android ? other Chromium and FireFox derived browsers maybe affected. Internet Explorer andSafari are not affected. The issue is exploitable remotely, albeit not easily. Details Because browsers include multiple non-HTTPS search engines which also use non-HTTPS endpoints, it would be possible for an attacker on the network level to intercept the traffic flowing between the browser and the search engine endpoints, and substitute their own. If a very large response is returned (2+ GBs), the browser can run out of memory and crash. This is due to the fact that browsers do not check for sizes in the search suggestions responses. Obviously, this is more of an issue for mobile devices which have lower memory than desktops. For Android AOSP browser and Chromium, this issue appear to be directly tied to the processing code of search engine responses. For FireFox, this is a more generic issue around large XMLHTTPRequest responses, which is what the browser is using internally for search suggestions. Our bug reports with the vendors provide more details on which code is causing this. This re-enforces the fact network traffic SHOULD NEVER be trusted. The following crashes were observed ? we have not been able to cause an RCE or a buffer overflow: - Android AOSP stock browser on Android (v4.4) ? application crashes - Chrome v51 on Android (v6.01) ? application crashes - Chrome v51 on desktop Linux (Ubuntu v16.04) ? the entire computer freezes requires a reboot (this maybe to due to swapping being disabled with an SSD drive) - FireFox v47 on desktop Linux (Ubuntu v16.04) and Android (v6.01) ? application crashes Safari v9.1 and Internet Explorer 11 and Edge appear not to be affected, although a similar bug has happened before with Safari. We did not test prior versions of either Safari or IE. We also did not test any other browsers derived from Chromium or FireFox. The practical exploitation of this issue is mitigated by several factors: - The attacker must have control over DNS and the network traffic of the victim machine. This is most likely in cases of a rogue WiFi hotspot or a hacked router. - Most browsers have a rather short timeout for search engine suggestions response, not allowing sufficient time for the large response packet to be transferred over network - Due to the very large response size needed to trigger this issue, it is only exploitable over broadband or local networks such as rogue WiFi hotspot Vendor Responses Google response re: Android AOSP browser: "The team reviewed this issue and don?t believe there is a security vulnerability here. It seems the worse things that can happen is the browser crashes due to resource exhaustion. The phone is still usable so there isn?t a denial of service." Google response re: Chromium: "We don?t consider DoS to be a security vulnerability. See the Chrome Security FAQ: https://www.chromium.org/Home/chromium-security/security-faq#TOC-Are-denial-of-service-issues-considered-security-bugs-"; Mozilla / FireFox response has been to remove the security restriction on this bug, therefore indicating that this is not a security issue. References Android bug reports: 214784 and 214785 Chromium bug reports: 624779 and 624794 FireFox bug reports: 1283675 and 1283672 Timeline 2016-06-30: Bug filed with Android 2016-06-30: Bug filed with Chromium 2016-06-30: Bug filed Mozilla/FireFox 2016-06-30: Response from Chromium, Won?t Fix 2016-07-12: Response from Android, not a security issue 2016-07-13: Android team is ok with disclosure 2016-07-14: Mozilla removes security restrictions on the bug 2016-07-26: Public disclosure
