Author Archives: Scott Westover

PHA Family Highlights: Bread (and Friends)




“So..good..”
“very beautiful”
Later, 1 star reviews from real users start appearing with comments like:
“Deception”
“The app is not honest …”

SUMMARY

Sheer volume appears to be the preferred approach for Bread developers. At different times, we have seen three or more active variants using different approaches or targeting different carriers. Within each variant, the malicious code present in each sample may look nearly identical with only one evasion technique changed. Sample 1 may use AES-encrypted strings with reflection, while Sample 2 (submitted on the same day) will use the same code but with plaintext strings.
At peak times of activity, we have seen up to 23 different apps from this family submitted to Play in one day. At other times, Bread appears to abandon hope of making a variant successful and we see a gap of a week or longer before the next variant. This family showcases the amount of resources that malware authors now have to expend. Google Play Protect is constantly updating detection engines and warning users of malicious apps installed on their device.

SELECTED SAMPLES

Package Name SHA-256 Digest
com.rabbit.artcamera 18c277c7953983f45f2fe6ab4c7d872b2794c256604e43500045cb2b2084103f
org.horoscope.astrology.predict 6f1a1dbeb5b28c80ddc51b77a83c7a27b045309c4f1bff48aaff7d79dfd4eb26
com.theforest.rotatemarswallpaper 4e78a26832a0d471922eb61231bc498463337fed8874db5f70b17dd06dcb9f09
com.jspany.temp 0ce78efa764ce1e7fb92c4de351ec1113f3e2ca4b2932feef46d7d62d6ae87f5
com.hua.ru.quan 780936deb27be5dceea20a5489014236796a74cc967a12e36cb56d9b8df9bc86
com.rongnea.udonood 8b2271938c524dd1064e74717b82e48b778e49e26b5ac2dae8856555b5489131
com.mbv.a.wp 01611e16f573da2c9dbc7acdd445d84bae71fecf2927753e341d8a5652b89a68
com.pho.nec.sg b4822eeb71c83e4aab5ddfecfb58459e5c5e10d382a2364da1c42621f58e119b

Better password protections in Chrome – How it works



Today, we announced better password protections in Chrome, gradually rolling out with release M79. Here are the details of how they work.


Warnings about compromised passwords
Google first introduced password breach warnings as a Password Checkup extension early this year. It compares passwords and usernames against over 4 billion credentials that Google knows to have been compromised. You can read more about it here. In October, Google built the Password Checkup feature into the Google Account, making it available from passwords.google.com.

Chrome’s integration is a natural next step to ensure we protect even more users as they browse the web. Here is how it works:
  • Whenever Google discovers a username and password exposed by another company’s data breach, we store a hashed and encrypted copy of the data on our servers with a secret key known only to Google.
  • When you sign in to a website, Chrome will send a hashed copy of your username and password to Google encrypted with a secret key only known to Chrome. No one, including Google, is able to derive your username or password from this encrypted copy.
  • In order to determine if your username and password appears in any breach, we use a technique called private set intersection with blinding that involves multiple layers of encryption. This allows us to compare your encrypted username and password with all of the encrypted breached usernames and passwords, without revealing your username and password, or revealing any information about any other users’ usernames and passwords. In order to make this computation more efficient, Chrome sends a 3-byte SHA256 hash prefix of your username to reduce the scale of the data joined from 4 billion records down to 250 records, while still ensuring your username remains anonymous.
  • Only you discover if your username and password have been compromised. If they have been compromised, Chrome will tell you, and we strongly encourage you to change your password.

You can control this feature in the “Sync and Google Services” section of Chrome Settings. Enterprise admins can control this feature using the Password​Leak​Detection​Enabled policy setting.


Real-time phishing protection: Checking with Safe Browsing’s blocklist in real time.
Chrome’s new real-time phishing protection is also expanding existing technology — in this case it’s Google’s well-established Safe Browsing.

Every day, Safe Browsing discovers thousands of new unsafe sites and adds them to the blocklists shared with the web industry. Chrome checks the URL of each site you visit or file you download against this local list, which is updated approximately every 30 minutes. If you navigate to a URL that appears on the list, Chrome checks a partial URL fingerprint (the first 32 bits of a SHA-256 hash of the URL) with Google for verification that the URL is indeed dangerous. Google cannot determine the actual URL from this information.

However, we’re noticing that some phishing sites slip through our 30-minute refresh window, either by switching domains very quickly or by hiding from Google's crawlers.

That’s where real-time phishing protections come in. These new protections can inspect the URLs of pages visited with Safe Browsing’s servers in real time. When you visit a website, Chrome checks it against a list stored on your computer of thousands of popular websites that are known to be safe. If the website is not on the safe-list, Chrome checks the URL with Google (after dropping any username or password embedded in the URL) to find out if you're visiting a dangerous site. Our analysis has shown that this results in a 30% increase in protections by warning users on malicious sites that are brand new.

We will be initially rolling out this feature for people who have already opted-in to “Make searches and browsing better” setting in Chrome. Enterprises administrators can manage this setting via the Url​Keyed​Anonymized​Data​Collection​Enabled policy settings.


Expanding predictive phishing protection
Your password is the key to your online identity and data. If this key falls into the hands of attackers, they can easily impersonate you and get access to your data. We launched predictive phishing protections to warn users who are syncing history in Chrome when they enter their Google Account password into suspected phishing sites that try to steal their credentials.

With this latest release, we’re expanding this protection to everyone signed in to Chrome, even if you have not enabled Sync. In addition, this feature will now work for all the passwords you have stored in Chrome’s password manager.

If you type one of your protected passwords (this could be a password you stored in Chrome’s password manager, or the Google Account password you used to sign in to Chrome) into an unusual site, Chrome classifies this as a potentially dangerous event.

In such a scenario, Chrome checks the site against a list on your computer of thousands of popular websites that are known to be safe. If the website is not on the safe-list, Chrome checks the URL with Google (after dropping any username or password embedded in the URL). If this check determines that the site is indeed suspicious or malicious, Chrome will immediately show you a warning and encourage you to change your compromised password. If it was your Google Account password that was phished, Chrome also offers to notify Google so we can add additional protections to ensure your account isn't compromised.

By watching for password reuse, Chrome can give heightened security in critical moments while minimizing the data it shares with Google. We think predictive phishing protection will protect hundreds of millions more people.

An Update on Android TLS Adoption

Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security

banner illustration with several devices and gaming controller

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.

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 in Android Studio.

Example of a warning shown to developers as part of the pre-launch report.

Example of a warning shown to developers as part of the pre-launch report.

What can I do to secure my app?

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>

What can I do to secure my library?

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.

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

Expanding the Android Security Rewards Program

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:

  • Total payouts in the last 12 months have been over $1.5 million.
  • Over 100 participating researchers have received an average reward amount of over $3,800 per finding (46% increase from last year). On average, this means we paid out over $15,000 (20% increase from last year) per researcher!
  • The top reward paid out in 2019 was $161,337.

Top Payout

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!

GWP-ASan: Sampling heap memory error detection in-the-wild

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:

  • Coverage-guided fuzzing with AddressSanitizer (ASan)
  • Unit and integration testing with ASan
  • Defensive programming, like custom libraries to perform safe math or provide bounds checked containers
  • Mandatory code review

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.

GWP-ASan: Sampling heap memory error detection in-the-wild

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:

  • Coverage-guided fuzzing with AddressSanitizer (ASan)
  • Unit and integration testing with ASan
  • Defensive programming, like custom libraries to perform safe math or provide bounds checked containers
  • Mandatory code review

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.

The App Defense Alliance: Bringing the security industry together to fight bad apps


Fighting against bad actors in the ecosystem is a top priority for Google, but we know there are others doing great work to find and protect against attacks. Our research partners in the mobile security world have built successful teams and technology, helping us in the fight. Today, we’re excited to take this collaboration to the next level, announcing a partnership between Google, ESET, Lookout, and Zimperium. It’s called the App Defense Alliance and together, we’re working to stop bad apps before they reach users’ devices.
The Android ecosystem is thriving with over 2.5 billion devices, but this popularity also makes it an attractive target for abuse. This is true of all global platforms: where there is software with worldwide proliferation, there are bad actors trying to attack it for their gain. Working closely with our industry partners gives us an opportunity to collaborate with some truly talented researchers in our field and the detection engines they’ve built. This is all with the goal of, together, reducing the risk of app-based malware, identifying new threats, and protecting our users.
What will the App Defense Alliance do?
Our number one goal as partners is to ensure the safety of the Google Play Store, quickly finding potentially harmful applications and stopping them from being published
As part of this Alliance, we are integrating our Google Play Protect detection systems with each partner’s scanning engines. This will generate new app risk intelligence as apps are being queued to publish. Partners will analyze that dataset and act as another, vital set of eyes prior to an app going live on the Play Store.
Who are the partners?
All of our partners work in the world of endpoint protection, and offer specific products to protect mobile devices and the mobile ecosystem. Like Google Play Protect, our partners’ technologies use a combination of machine learning and static/dynamic analysis to detect abusive behavior. Multiple heuristic engines working in concert will increase our efficiency in identifying potentially harmful apps.
We hand-picked these partners based on their successes in finding potential threats and their dedication to improving the ecosystem. These partners are regularly recognized in analyst reports for their work.
Industry collaboration is key
Knowledge sharing and industry collaboration are important aspects in securing the world from attacks. We believe working together is the ultimate way we will get ahead of bad actors. We’re excited to work with these partners to arm the Google Play Store against bad apps.
Want to learn more about the App Defense Alliance’s work? Visit us here.

The App Defense Alliance: Bringing the security industry together to fight bad apps


Fighting against bad actors in the ecosystem is a top priority for Google, but we know there are others doing great work to find and protect against attacks. Our research partners in the mobile security world have built successful teams and technology, helping us in the fight. Today, we’re excited to take this collaboration to the next level, announcing a partnership between Google, ESET, Lookout, and Zimperium. It’s called the App Defense Alliance and together, we’re working to stop bad apps before they reach users’ devices.
The Android ecosystem is thriving with over 2.5 billion devices, but this popularity also makes it an attractive target for abuse. This is true of all global platforms: where there is software with worldwide proliferation, there are bad actors trying to attack it for their gain. Working closely with our industry partners gives us an opportunity to collaborate with some truly talented researchers in our field and the detection engines they’ve built. This is all with the goal of, together, reducing the risk of app-based malware, identifying new threats, and protecting our users.
What will the App Defense Alliance do?
Our number one goal as partners is to ensure the safety of the Google Play Store, quickly finding potentially harmful applications and stopping them from being published
As part of this Alliance, we are integrating our Google Play Protect detection systems with each partner’s scanning engines. This will generate new app risk intelligence as apps are being queued to publish. Partners will analyze that dataset and act as another, vital set of eyes prior to an app going live on the Play Store.
Who are the partners?
All of our partners work in the world of endpoint protection, and offer specific products to protect mobile devices and the mobile ecosystem. Like Google Play Protect, our partners’ technologies use a combination of machine learning and static/dynamic analysis to detect abusive behavior. Multiple heuristic engines working in concert will increase our efficiency in identifying potentially harmful apps.
We hand-picked these partners based on their successes in finding potential threats and their dedication to improving the ecosystem. These partners are regularly recognized in analyst reports for their work.
Industry collaboration is key
Knowledge sharing and industry collaboration are important aspects in securing the world from attacks. We believe working together is the ultimate way we will get ahead of bad actors. We’re excited to work with these partners to arm the Google Play Store against bad apps.
Want to learn more about the App Defense Alliance’s work? Visit us here.

Protecting against code reuse in the Linux kernel with Shadow Call Stack


The Linux kernel is responsible for enforcing much of Android’s security model, which is why we have put a lot of effort into hardening the Android Linux kernel against exploitation. In Android 9, we introduced support for Clang’s forward-edge Control-Flow Integrity (CFI) enforcement to protect the kernel from code reuse attacks that modify stored function pointers. This year, we have added backward-edge protection for return addresses using Clang’s Shadow Call Stack (SCS).
Google’s Pixel 3 and 3a phones have kernel SCS enabled in the Android 10 update, and Pixel 4 ships with this protection out of the box. We have made patches available to all supported versions of the Android kernel and also maintain a patch set against upstream Linux. This post explains how kernel SCS works, the benefits and trade-offs, how to enable the feature, and how to debug potential issues.

Return-oriented programming

As kernel memory protections increasingly make code injection more difficult, attackers commonly use control flow hijacking to exploit kernel bugs. Return-oriented programming (ROP) is a technique where the attacker gains control of the kernel stack to overwrite function return addresses and redirect execution to carefully selected parts of existing kernel code, known as ROP gadgets. While address space randomization and stack canaries can make this attack more challenging, return addresses stored on the stack remain vulnerable to many overwrite flaws. The general availability of tools for automatically generating this type of kernel exploit makes protecting against it increasingly important.

Shadow Call Stack

One method of protecting return addresses is to store them in a separately allocated shadow stack that’s not vulnerable to traditional buffer overflows. This can also help protect against arbitrary overwrite attacks.
Clang added the Shadow Call Stack instrumentation pass for arm64 in version 7. When enabled, each non-leaf function that pushes the return address to the stack will be instrumented with code that also saves the address to a shadow stack. A pointer to the current task’s shadow stack is always kept in the x18 register, which is reserved for this purpose. Here’s what instrumentation looks like in a typical kernel function:

SCS doesn’t require error handling as it uses the return address from the shadow stack unconditionally. Compatibility with stack unwinding for debugging purposes is maintained by keeping a copy of the return address in the normal stack, but this value is never used for control flow decisions.
Despite requiring a dedicated register, SCS has minimal performance overhead. The instrumentation itself consists of one load and one store instruction per function, which results in a performance impact that’s within noise in our benchmarking. Allocating a shadow stack for each thread does increase the kernel’s memory usage but as only return addresses are stored, the stack size defaults to 1kB. Therefore, the overhead is a fraction of the memory used for the already small regular kernel stacks.
SCS patches are available for Android kernels 4.14 and 4.19, and for upstream Linux. It can be enabled using the following configuration options:

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.

Alternatives

Signing return addresses using ARMv8.3 Pointer Authentication (PAC) is an alternative to shadow stacks. PAC has similar security properties and comparable performance to SCS but without the memory allocation overhead. Unfortunately, PAC requires hardware support, which means it cannot be used on existing devices, but may be a viable option for future devices. For x86, Intel’s Control-flow Enforcement Technology (CET) extension will offer a native shadow stack support, but also requires compatible hardware.

Conclusion

We have improved Linux kernel code reuse attack protections on Pixel devices running Android 10. Pixel 3, 3a, and 4 kernels have both CFI and SCS enabled and we have made patches available to all Android OEMs.

Protecting against code reuse in the Linux kernel with Shadow Call Stack


The Linux kernel is responsible for enforcing much of Android’s security model, which is why we have put a lot of effort into hardening the Android Linux kernel against exploitation. In Android 9, we introduced support for Clang’s forward-edge Control-Flow Integrity (CFI) enforcement to protect the kernel from code reuse attacks that modify stored function pointers. This year, we have added backward-edge protection for return addresses using Clang’s Shadow Call Stack (SCS).
Google’s Pixel 3 and 3a phones have kernel SCS enabled in the Android 10 update, and Pixel 4 ships with this protection out of the box. We have made patches available to all supported versions of the Android kernel and also maintain a patch set against upstream Linux. This post explains how kernel SCS works, the benefits and trade-offs, how to enable the feature, and how to debug potential issues.

Return-oriented programming

As kernel memory protections increasingly make code injection more difficult, attackers commonly use control flow hijacking to exploit kernel bugs. Return-oriented programming (ROP) is a technique where the attacker gains control of the kernel stack to overwrite function return addresses and redirect execution to carefully selected parts of existing kernel code, known as ROP gadgets. While address space randomization and stack canaries can make this attack more challenging, return addresses stored on the stack remain vulnerable to many overwrite flaws. The general availability of tools for automatically generating this type of kernel exploit makes protecting against it increasingly important.

Shadow Call Stack

One method of protecting return addresses is to store them in a separately allocated shadow stack that’s not vulnerable to traditional buffer overflows. This can also help protect against arbitrary overwrite attacks.
Clang added the Shadow Call Stack instrumentation pass for arm64 in version 7. When enabled, each non-leaf function that pushes the return address to the stack will be instrumented with code that also saves the address to a shadow stack. A pointer to the current task’s shadow stack is always kept in the x18 register, which is reserved for this purpose. Here’s what instrumentation looks like in a typical kernel function:

SCS doesn’t require error handling as it uses the return address from the shadow stack unconditionally. Compatibility with stack unwinding for debugging purposes is maintained by keeping a copy of the return address in the normal stack, but this value is never used for control flow decisions.
Despite requiring a dedicated register, SCS has minimal performance overhead. The instrumentation itself consists of one load and one store instruction per function, which results in a performance impact that’s within noise in our benchmarking. Allocating a shadow stack for each thread does increase the kernel’s memory usage but as only return addresses are stored, the stack size defaults to 1kB. Therefore, the overhead is a fraction of the memory used for the already small regular kernel stacks.
SCS patches are available for Android kernels 4.14 and 4.19, and for upstream Linux. It can be enabled using the following configuration options:

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.

Alternatives

Signing return addresses using ARMv8.3 Pointer Authentication (PAC) is an alternative to shadow stacks. PAC has similar security properties and comparable performance to SCS but without the memory allocation overhead. Unfortunately, PAC requires hardware support, which means it cannot be used on existing devices, but may be a viable option for future devices. For x86, Intel’s Control-flow Enforcement Technology (CET) extension will offer a native shadow stack support, but also requires compatible hardware.

Conclusion

We have improved Linux kernel code reuse attack protections on Pixel devices running Android 10. Pixel 3, 3a, and 4 kernels have both CFI and SCS enabled and we have made patches available to all Android OEMs.