chrome

Behavior Change in Chrome’s Download Protection Service Affecting Privacy

nightwatchcyber Research

The Download Protection service in Chrome protects users from downloading malware/viruses by blocking files that are known to be unsafe by the Google’s Safe Browsing service. The way this works is that Chrome sends some basic information about the file being downloaded including the checksum to the Safe Browsing service and receives a verdict.

Historically, not all file types were checked – instead a list of extensions to be checked or ignored is defined in the Chrome source code and only those extensions would be checked. Any extensions not on the list are ignored. These lists can be found in the following file (“download_file_types.asciipb”).

Apparently, this has been changed recently. As per information provided from a recent bug report (https://crbug.com/1039128), Chrome now checks ALL extensions except for the ones on the whitelist. That means when you download almost any file, the checksum and some other information about the file are sent back to Google. It is not clear how this impacts privacy. Since other browsers use this API, it may impact them as well.

You can disable this behavior by disabling the Safe Browsing API entirely but that will also disable checks for malicious URLs. As of now, there doesn’t seem to be an option to disable download protection separately from safe browsing for URLs. The Safe Browsing API does include an option to download a list of dangerous files locally but it doesn’t appear that Chrome uses it yet.

You can see this information by typing the following in your Chrome’s URL bar and checking the “Download Protection” tab.

Example of a MRC file being downloaded from the Internet Archive:

Screen Shot 2020-01-12 at 10.30.18 AM

For some files (primarily ZIPs) a hash is sent as well. You can see this when trying to download the EICAR test file (standard test file for antivirus software):

{
"archive_directory_count": 0,
"archive_file_count": 1,
"archive_valid": true,
"archived_binary": [ {
"digests": {
"sha256": "2546DCFFC5AD854D4DDC64FBF056871CD5A00F2471CB7A5BFD4AC23B6E9EEDAD"
},
"download_type": 6,
"file_basename": "eicar_com.zip",
"length": 184
} ],
"download_type": 5,
"file_basename": "eicarcom2.zip",
"length": 308,
"referrer_chain": [ {
"ip_addresses": [ "89.238.73.97" ],
"is_retargeting": false,
"is_subframe_referrer_url_removed": false,
"is_subframe_url_removed": false,
"main_frame_url": "",
"maybe_launched_by_external_application": false,
"navigation_initiation": "RENDERER_INITIATED_WITH_USER_GESTURE",
"navigation_time_msec": 1.628252679503e+12,
"referrer_main_frame_url": "",
"referrer_url": "https://www.eicar.org/?page_id=3950",
"server_redirect_chain": [ ],
"type": "EVENT_URL",
"url": "https://secure.eicar.org/eicarcom2.zip"
}, {
"ip_addresses": [ "89.238.73.97" ],
"is_retargeting": false,
"is_subframe_referrer_url_removed": false,
"is_subframe_url_removed": false,
"main_frame_url": "",
"maybe_launched_by_external_application": false,
"navigation_initiation": "RENDERER_INITIATED_WITH_USER_GESTURE",
"navigation_time_msec": 1.628252674199e+12,
"referrer_main_frame_url": "",
"referrer_url": "https://www.google.com/search?q=antivirustst+file&oq=antivirustst+file",
"server_redirect_chain": [ ],
"type": "LANDING_PAGE",
"url": "https://www.eicar.org/?page_id=3950"
}, {
"ip_addresses": [ "142.250.65.196" ],
"is_retargeting": false,
"is_subframe_referrer_url_removed": false,
"is_subframe_url_removed": false,
"main_frame_url": "",
"maybe_launched_by_external_application": false,
"navigation_initiation": "BROWSER_INITIATED",
"navigation_time_msec": 1.62825267089e+12,
"referrer_main_frame_url": "",
"referrer_url": "",
"server_redirect_chain": [ ],
"type": "LANDING_REFERRER",
"url": "https://www.google.com/search?q=antivirustst+file&oq=antivirustst+file"
} ],
"request_ap_verdicts": false,
"url": "https://secure.eicar.org/eicarcom2.zip"
}

Credits

Written by Y. Shafranovich.

Another Download Protection Bypass in Google Chrome – BIN files in Mac OS

nightwatchcyber Advisories ,

Summary

BIN files on Mac OS bypass the download protection mechanism offered by Google’s Chrome browser. This was reported and fixed by the vendor, then pushed via a component update to users in March 2019.

Background

The Chrome and Chromium browsers are an open-source based web browser offered by Google. Among it’s features it includes a safety feature that detects unsafe downloads to protect the user. This feature works in multiple ways but is controlled via a file in Chrome’s source code (“download_file_types.asciipb”). Additional background details can be found in our earlier post. We had previously reported multiple instances of download protection bypass in Chrome to the vendor – this post describes another one that was found more recently.

Details

The BIN file extension on Mac OS is opened by default via the Archive Mounter utility. That means that you can take a compressed file such as ZIP and rename it as a BIN file. When downloaded via Chrome, the browser will not do safety checks on this file yet the file can carry dangerous content. The root cause is the fact that the BIN file type is whitelisted as being not dangerous. This issue only affects users on Mac OS.

The vendor fixed the issue and pushed it via a component update. Users do not need to update the actual browser – as long as connectivity exists for component updates, this should be fixed automatically.

References

Chrome Bug Report: 933637

Bounty Information

This issue qualified for the Chrome Rewards security bounty program and a bounty has been paid.

Credits

Advisory written by Y. Shafranovich.

Timeline Summary

2019-02-19: Report submitted
2019-02-27: Vendor fix is committed
2019-03-25: Vendor fix is released to users
2019-07-02: Public disclosure

 

Two Bugs in Google Chrome

nightwatchcyber Advisories ,

Summary

Google Chrome has two places (credits pages and default sites) where HTTP links are used instead of HTTPS, which can lead to MITM attacks on a hostile network. The vendor doesn’t consider these to be security bugs and they remain unfixed.

Bug Details – Default Sites

On startup, Chrome for Android displays a search bat and 8 icons of commonly accessed sites. If the browser has not yet collected any history data, those icons default to the ones provided by a Google-hosted service (“https://www.gstatic.com/chrome/ntp/suggested_sites_DEFAULT_5.json“). These default sites are country specific. However, not all of these links use HTTPS – some use HTTP. As the result if a user is on a hostile network and taps any of these sites, the connection can be intercepted by an MITM attacker.

While this issue was seen in Android, it may affect other platforms.

Screenshots:

Screenshot_20171122-215523 Screen Shot 2019-05-27 at 12.37.41 PM

Bug Details – Credits Page

Chrome has a credits page (“chrome://credits“) that contains licensing information and links to various open source projects. Not all of these links use HTTPS, instead some use HTTP. As the result if a user is on a hostile network and taps any of these sites, the connection can be intercepted by an MITM attacker. This can be seen by going to the URL (“chrome://credits“) or going to “Help”, “About”, “Open Source Licenses”.

This impacts all platforms that Chrome supports including Linux, Windows, Android, iOS, MacOS and ChromeOS.

Screenshots:

Screenshot_20190527-123241 Screenshot_20190527-123253  Screenshot_20190527-123307

Vendor Response

The vendor doesn’t consider these to be security bugs and they remain unfixed.

References

Chromium Bugs: 788055 and 927139

Credits

Advisory written by Y. Shafranovich.

Timeline

2017-11-22: Default sites bug (#788055) reported to the vendor
2017-11-23: Initial vendor response (#788055), not considered a security bug
2017-11-23: Vendor response (#788055)
2019-01-30: Credits bug (#927139) reported to the vendor
2019-01-30: Initial vendor response (#927139), not considered a security bug
2019-01-30: Vendor response (#927139)
2019-04-01: Checking with vendor regarding disclosure (#788055)
2019-05-27: Public disclosure for both

Multiple Instances of Download Protection Bypass in Google’s Chrome

nightwatchcyber Advisories ,

Summary

We have found several instances of files bypassing the download protection offered by Google’s Chrome browser. All of these have been reported to the vendor, and whichever were accepted by the vendor were fixed in Chrome M51 and M52.

Background

The Chrome and Chromium browsers are an open-source based web browser offered by Google. Among it’s features it includes a safety feature that detects unsafe downloads to protect the user. This feature works in multiple ways but is controlled via a file in Chrome’s source code (“download_file_types.asciipb”) which defines several options based on what the file extension of the downloaded files are:

  • Platform/OS
  • What kind of warning to show the user
  • Whether this file type is an archive
  • Whether the file can be opened automatically by clicking on it in the download area
  • Whether a ping get sent back to Google for every download of this type (FULL), some downloads (SAMPLED) or not sent at all. This checksum check is used to check against a server-side blacklist of known bad files.

The Chrome Rewards bug bounty program includes a separate section covering download bypass that was added in March of 2016. To be eligible, it needs to be on a supported platform (MacOS or Windows), be dangerous by being clicked and not send a full ping back to Google. In December of 2016, the scope of this was changed to only include file extensions already in the source code for Chrome.

As part of our testing in scope of this program, we tested all file extensions that are included in a default on MacOS v10.11 (El Capitan)  and Windows 2012 R2 / 7 Enterprise. This advisory lists all of the bypasses that we located, reported to the vendor, and the status of whether they were accepted and fixed, or rejected. Most of these were reported prior to the scope change in December 2016, and included patches whenever feasible.

Details

The following extensions were reported but were rejected as being out of scope and were not fixed:

  • ChromeOS: APK
  • Linux: AFM, PFA, TIF
  • MacOS: APP, CONFIGPROFILE, DFONT, ICC, INTERNETCONNECT, MOBILECONFIG, NETWORKCONNECT, OTF, PREFPANE, PROVISIONPROFILE, QTZ, SAFARIEXTZ, SAVER, TTF, WEBBOOKMARK, WEBLOC
  • Windows: CAMP, CDMP, DESKTHEMEPACK, DIAGCAB, DIAGPKG, GMMP, ICC, IMESX, MOV, MSU, OTF, PFB, PFM, PRF, RAT, QDS, QT, RDP, SEARCH-MS, THEMEPACK, THEMES, TTC, TTF, WCX

The following extensions were reported, confirmed to be dangerous and fixed, all on MacOS (the underlying issue has been described in a separate blog post here).

  • AS, CDR, CPGZ, DART, DC42, DISKCOPY42, DMGPART, DVDR, IMG, IMGPART, ISO, MPKG, NDIF, PAX, SMI, SPARSEBUNDLE, SPARSEIMAGE, TOAST, UDIF, XIP

These issues were fixed in Chrome M51 and M52.

References

Chrome Bug Reports (rejected): 671382, 671385, 624224, 596342, 605386, 601255, 601250, 600910, 600615, 600609, 600606, 600601, 600597, 600592, 600590, 600587, 600581, 599880

Chrome Bug Reports (fixed): 596354, 600613, 600907, 600908

Bounty Information

The issues that were fixed qualified for the Chrome Rewards security bounty program and a bounty has been paid.

Credits

Advisory written by Yakov Shafranovich.

Timeline Summary

2016-03-20: First report submitted
2016-03 to 2016-12: multiple other reports submitted, and fixed applied
2016-12-06: Last report submitted
2018-02-26: Public disclosure

 

ChromeOS Doesn’t Always Use SSL During Startup [CVE-2017-15397]

nightwatchcyber Advisories , , ,

Summary

ChromeOS did not use SSL in all network calls originating from the ChromeVox component during startup. This could potentially have allowed an MITM attacker to inject content into ChromeOS or crash the device. The vendor (Google) fixed this issue in Chrome M62. Google has assigned CVE-2017-15397 to track this issue.

Details

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.

By monitoring network traffic using a proxy we noticed that some network calls originating from the ChromeVox component did not use SSL. These calls occured during the startup process before a user logged in. Because these calls did not use SSL, it would be possible for an MITM attacker, in theory, to either inject their own content into ChromeOS, or crash the device by sending a very large packet. We did not conduct any follow-up testing to confirm either of these two possibilities.

To reproduce:
1. Setup a proxy with WiFi.
2. Switch ChromeOS device to use proxy.
3. Restart the device and on the login screen enable ChromeVox.
4. Observe calls to HTTP without SSL.

All testing was done on an Acer ChromeBook, running Chrome version 51.0.2704.106 *stable) and ChromeOS version 8172.62.0 (stable).

Vendor Response

This issue was responsibly reported to the vendor via the Chromium bug tracker. The vendor fixed this issue in ChromeOS release M62 and assigned CVE-2017-15397 to track it.

References

CVE ID: CVE-2017-15397
Chromium Bug # 627300

Bounty Information

This bug qualified for a bounty under the terms of the Google Chrome Rewards bounty program, and a bounty payment has been received.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-07-12: Initial report to the vendor
2017-09-18: Issue patched by the vendor
2017-10-26: CVE assigned by the vendor
2018-01-01: Public disclosure

Chrome for Android Didn’t Use FLAG_SECURE for Credit Card Prefill Settings [CVE-2017-5082]

nightwatchcyber Advisories , ,

Summary

Chrome for Android did not use the FLAG_SECURE flag in the credit card prefills settings, potentially exposing sensitive data to other applications on the same device with the screen capture permissions. The vendor (Google) fixed this issue in Chrome M59. Google has assigned CVE-2017-5082 to track this issue.

Details

Chrome for Android is a version of the Chrome browser for Android platforms. It used to be part of the Android OS, but is now a separate application deployed by Google through the Google Play store. Chrome has a credit card pre-fills section in settings where users can store credit card information that can be used to pre-fill certain forms.

FLAG_SECURE is a special flag available to Android developers that prevents a particular screen within an application from being seen by other application with screen capture permissions, having screenshots taken by the user, or have the screen captured in the “Recent Apps” portion of Android OS. We have published an extensive post last year discussing this feature is and what it does.

During our testing of various Google mobile applications, we found that the credit card prefills section in Chrome for Android did not use FLAG_SECURE to prevent other applications for capturing that information. By contrast other Google applications like Android Pay and Google Wallet use this flag to prevent capture of sensitive information. Exploiting this bug requires user cooperation in installing a malicious app and activating the actual screen capture process, thus the likehood of exploitation is low.

To reproduce:
1. Open Chrome.
2. To go Settings, Autofill and payments, Credit Cards.
3. Tap on “Add credit card”.
4. Press Power and volume down to capture screenshot.
5. Confirm that a screenshot can be taken.

 

All testing was done on Android 7.1.2, security patch level of May 5th, 2017, on Chrome v58.0.3029.83 (stable).

Vendor Response

This issue was responsibly reported to the vendor via the Chromium bug tracker. The vendor fixed this issue in Chrome release M59 and assigned CVE-2017-5082 to track it.

References

CVE ID: CVE-2017-5082
Chromium Bug # 721579

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-15: Issue patched by the vendor
2016-05-30: CVE assigned by the vendor
2016-06-05: Fixed version released
2016-07-16: Request for public disclosure sent to the vendor
2017-07-26: Permission to disclose received
2017-07-27: Public disclosure

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

nightwatchcyber Advisories , , ,

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: Chrome For Android Reveals Phone Model and Build

nightwatchcyber Research , ,

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

Overview

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.

Details

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.

Conclusion

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.

and:

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.

Credits

Researched and written by Yakov Shafranovich.