bugtraq - Crashing Browsers Remotely via Insecure Search Suggestions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Tue, 26 Jul 2016 09:36:10 GMT
From: research@...htwatchcybersecurity.com
To: bugtraq@...urityfocus.com
Subject: Crashing Browsers Remotely via Insecure Search Suggestions

[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