Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security
Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting network traffic that enters or leaves an Android device with Transport Layer Security (TLS).
Android 7 (API level 24) introduced the Network Security Configuration in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a policy set by default that prevents unencrypted traffic for every domain.
Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default.
Percentage of apps that block cleartext by default.
Since November 1 2019, all app (updates as well as all new apps on Google Play) must target at least Android 9. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer.
The latest releases of Android Studio and Google Play’s pre-launch report warn developers when their app includes a potentially insecure Network Security Configuration (for example, when they allow unencrypted traffic for all domains or when they accept user provided certificates outside of debug mode). This encourages the adoption of HTTPS across the Android ecosystem and ensures that developers are aware of their security configuration.
Example of a warning shown to developers in Android Studio.
Example of a warning shown to developers as part of the pre-launch report.
For apps targeting Android 9 and higher, the out-of-the-box default is to encrypt all network traffic in transit and trust only certificates issued by an authority in the standard Android CA set without requiring any extra configuration. Apps can provide an exception to this only by including a separate Network Security Config file with carefully selected exceptions.
If your app needs to allow traffic to certain domains, it can do so by including a Network Security Config file that only includes these exceptions to the default secure policy. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.
<network-security-config> <base-config cleartextTrafficPermitted="false" /> <domain-config cleartextTrafficPermitted="true"> <domain includeSubdomains="true">insecure.example.com</domain> <domain includeSubdomains="true">insecure.cdn.example.com</domain> </domain-config> </network-security-config>
If your app needs to be able to accept user specified certificates for testing purposes (for example, connecting to a local server during testing), make sure to wrap your element inside a element. This ensures the connections in the production version of your app are secure.
<network-security-config> <debug-overrides> <trust-anchors> <certificates src="user"/> </trust-anchors> </debug-overrides> </network-security-config>
If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking isCleartextTrafficPermitted before opening any cleartext connection.
isCleartextTrafficPermitted
Android’s built-in networking libraries and other popular HTTP libraries such as OkHttp or Volley have built-in Network Security Config support.
Giles Hogben, Nwokedi Idika, Android Platform Security, Android Studio and Pre-Launch Report teams
The Android Security Rewards (ASR) program was created in 2015 to reward researchers who find and report security issues to help keep the Android ecosystem safe. Over the past 4 years, we have awarded over 1,800 reports, and paid out over four million dollars.
Today, we’re expanding the program and increasing reward amounts. We are introducing a top prize of $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. Additionally, we will be launching a specific program offering a 50% bonus for exploits found on specific developer preview versions of Android, meaning our top prize is now $1.5 million.
As mentioned in a previous blog post, in 2019 Gartner rated the Pixel 3 with Titan M as having the most “strong” ratings in the built-in security section out of all devices evaluated. This is why we’ve created a dedicated prize to reward researchers for exploits found to circumvent the secure elements protections.
In addition to exploits involving Pixel Titan M, we have added other categories of exploits to the rewards program, such as those involving data exfiltration and lockscreen bypass. These rewards go up to $500,000 depending on the exploit category. For full details, please refer to the Android Security Rewards Program Rules page.
Now that we’ve covered some of what’s new, let’s take a look back at some milestones from this year. Here are some highlights from 2019:
The highest reward paid out to a member of the research community was for a report from Guang Gong (@oldfresher) of Alpha Lab, Qihoo 360 Technology Co. Ltd. This report detailed the first reported 1-click remote code execution exploit chain on the Pixel 3 device. Guang Gong was awarded $161,337 from the Android Security Rewards program and $40,000 by Chrome Rewards program for a total of $201,337. The $201,337 combined reward is also the highest reward for a single exploit chain across all Google VRP programs. The Chrome vulnerabilities leveraged in this report were fixed in Chrome 77.0.3865.75 and released in September, protecting users against this exploit chain.
We’d like to thank all of our researchers for contributing to the security of the Android ecosystem. If you’re interested in becoming a researcher, check out our Bughunter University for information on how to get started.
Starting today November 21, 2019 the new rewards take effect. Any reports that were submitted before November 21, 2019 will be rewarded based on the previously existing rewards table.
Happy bug hunting!
Memory safety errors, like use-after-frees and out-of-bounds reads/writes, are a leading source of vulnerabilities in C/C++ applications. Despite investments in preventing and detecting these errors in Chrome, over 60% of high severity vulnerabilities in Chrome are memory safety errors. Some memory safety errors don’t lead to security vulnerabilities but simply cause crashes and instability.
Chrome uses state-of-the-art techniques to prevent these errors, including:
Chrome also makes use of sandboxing and exploit mitigations to complicate exploitation of memory errors that go undetected by the methods above.
AddressSanitizer is a compiler instrumentation that finds memory errors occurring on the heap, stack, or in globals. ASan is highly effective and one of the lowest overhead instrumentations available that detects the errors that it does; however, it still incurs an average 2-3x performance and memory overhead. This makes it suitable for use with unit tests or fuzzing, but not deployment to end users. Chrome used to deploy SyzyASAN instrumented binaries to detect memory errors. SyzyASAN had a similar overhead so it was only deployed to a small subset of users on the canary channel. It was discontinued after the Windows toolchain switched to LLVM.
GWP-ASan, also known by its recursive backronym, GWP-ASan Will Provide Allocation Sanity, is a sampling allocation tool designed to detect heap memory errors occurring in production with negligible overhead. Because of its negligible overhead we can deploy GWP-ASan to the entire Chrome user base to find memory errors happening in the real world that are not caught by fuzzing or testing with ASan. Unlike ASan, GWP-ASan can not find memory errors on the stack or in globals.
GWP-ASan is currently enabled for all Windows and macOS users for allocations made using malloc() and PartitionAlloc. It is only enabled for a small fraction of allocations and processes to reduce performance and memory overhead to a negligible amount. At the time of writing it has found over sixty bugs (many are still restricted view). About 90% of the issues GWP-ASan has found are use-after-frees. The remaining are out-of-bounds reads and writes.
To learn more, check out our full write up on GWP-ASan here.
CONFIG_SHADOW_CALL_STACK=y # CONFIG_SHADOW_CALL_STACK_VMAP is not set # CONFIG_DEBUG_STACK_USAGE is not set
By default, shadow stacks are not virtually allocated to minimize memory overhead, but CONFIG_SHADOW_CALL_STACK_VMAP can be enabled for better stack exhaustion protection. With CONFIG_DEBUG_STACK_USAGE, the kernel will also print out shadow stack usage in addition to normal stack usage which can be helpful when debugging issues.
Follow