Tag Archives: Security

Lock it up! New hardware protections for your lock screen with the Google Pixel 2


The new Google Pixel 2 ships with a dedicated hardware security module designed to be robust against physical attacks. This hardware module performs lockscreen passcode verification and protects your lock screen better than software alone.

To learn more about the new protections, let’s first review the role of the lock screen. Enabling a lock screen protects your data, not just against casual thieves, but also against sophisticated attacks. Many Android devices, including all Pixel phones, use your lockscreen passcode to derive the key that is then used to encrypt your data. Before you unlock your phone for the first time after a reboot, an attacker cannot recover the key (and hence your data) without knowing your passcode first. To protect against brute-force guessing your passcode, devices running Android 7.0+ verify your attempts in a secure environment that limits how often you can repeatedly guess. Only when the secure environment has successfully verified your passcode does it reveal a device and user-specific secret used to derive the disk encryption key.

Benefits of tamper-resistant hardware

The goal of these protections is to prevent attackers from decrypting your data without knowing your passcode, but the protections are only as strong as the secure environment that verifies the passcode. Performing these types of security-critical operations in tamper-resistant hardware significantly increases the difficulty of attacking it.
Tamper-resistant hardware comes in the form of a discrete chip separate from the System on a Chip (SoC). It includes its own flash, RAM, and other resources inside a single package, so it can fully control its own execution. It can also detect and defend against outside attempts to physically tamper with it.

In particular:
  • Because it has its own dedicated RAM, it’s robust against many side-channel information leakage attacks, such as those described in the TruSpy cache side-channel paper.
  • Because it has its own dedicated flash, it’s harder to interfere with its ability to store state persistently.
  • It loads its operating system and software directly from internal ROM and flash, and it controls all updates to it, so attackers can’t directly tamper with its software to inject malicious code.
  • Tamper-resistant hardware is resilient against many physical fault injection techniques including attempts to run outside normal operating conditions, such as wrong voltage, wrong clock speed, or wrong temperature. This is standardized in specifications such as the SmartCard IC Platform Protection Profile, and tamper-resistant hardware is often certified to these standards.
  • Tamper-resistant hardware is usually housed in a package that is resistant to physical penetration and designed to resist side channel attacks, including power analysis, timing analysis, and electromagnetic sniffing, such as described in the SoC it to EM paper.
Security module in Pixel 2

The new Google Pixel 2 ships with a security module built using tamper-resistant hardware that protects your lock screen and your data against many sophisticated hardware attacks.

In addition to all the benefits already mentioned, the security module in Pixel 2 also helps protect you against software-only attacks:
  • Because it performs very few functions, it has a super small attack surface.
  • With passcode verification happening in the security module, even in the event of a full compromise elsewhere, the attacker cannot derive your disk encryption key without compromising the security module first.
  • The security module is designed so that nobody, including Google, can update the passcode verification logic to a weakened version without knowing your passcode first.
Summary

Just like many other Google products, such as Chromebooks and Cloud, Android and Pixel are investing in additional hardware protections to make your device more secure. With the new Google Pixel 2, your data is safer against an entire class of sophisticated hardware attacks.

10 things you might be doing wrong when using the SafetyNet Attestation API

Posted by Oscar Rodriguez, Developer Advocate

The SafetyNet Attestation API helps you assess the security and compatibility of the Android environments in which your apps run. Since it was introduced in March 2015, many developers have successfully integrated it into their Android apps to make more informed decisions based on the integrity and compatibility of the devices running their apps.

Throughout the years, the SafetyNet Attestation API has evolved, and its adoption has steadily increased. However, as with any security/anti-abuse related API, there are many common pitfalls that may lead developers into developing unstable systems, or worse, into a false sense of security.

In this post, we provide a list of the most common mistakes we have seen developers make when integrating the SafetyNet Attestation API.

1. Not getting an API key

Just like many other Google APIs, the SafetyNet Attestation API requires an API key in order to run. Furthermore, the SafetyNet Attestation API has a per-key usage quota. Although you can get this quota increased, you need to provide your API key to do so.

Getting an API key is easy and free of charge. There is no reason not to get an API key, so if you haven't already, get an API key now.

2. Not using the latest version of the API

The SafetyNet Attestation API has evolved throughout its history, and with it, there have been some interface changes. Most recently, with the release of Google Play services 11.0.0, we revamped the entire SafetyNet API to offer an interface that is easier and more streamlined to use: the new API uses SafetyNetClient instead of SafetyNetApi, which is now deprecated, so make sure you update your implementation to use the latest version of the API.

Most devices should have the latest version of Google Play services installed, but if a device doesn't have Google Play services installed, or doesn't have it up to date, using the SafetyNet Attestation API may lead to the app becoming unresponsive or crashing. You can prevent this by checking the installed version of Google Play services before using the API.

3. Using nonces incorrectly

The SafetyNet Attestation API lets you set a nonce to uniquely and globally identify each call to the API. Use this feature to prevent a malicious user from reusing a successful attestation result in place of an unsuccessful result (also known as a Replay Attack).

One good way to create a nonce is to create a large (16 bytes or longer) random number on your server using a cryptographically-secure random function. The SafetyNet attestation response includes the nonce you set, so make sure you verify that the returned nonce matches the one you included in the request you made.

4. Not checking the results on your server

SafetyNet can provide useful signals about the state of the device in which your app is running. However, if the logic that acts on these signals is only implemented and enforced directly on the device, an attacker could be able to modify your app and bypass any checks you perform.

To prevent this situation, you should run any logic that verifies the attestation result and enforces any actions based on them on a server that you control and trust.

5. Using the test attestation verification service for production

In order to simplify development and testing of the SafetyNet Attestation API, Google offers an online verification service that checks the digital signature of a SafetyNet Attestation result using a simple HTTPS request.

As useful as this service may seem, it is designed for test purposes only, and it has very strict usage quotas that will not be increased upon request. Instead, you should implement the digital signature verification logic on your server in a way that it doesn't depend on Google's servers. Most JWT libraries offer signature verification functionality, and we have code samples that show how to perform this verification in Java and C#. We plan to provide samples for more languages in the future.

6. Not checking the nonce, timestamp, APK name, and hashes

The SafetyNet Attestation API is most widely known for its integrity and compatibility checks, whose results are returned in ctsProfileMatch and basicIntegrity. Although these two values are indeed very useful, you should check the other values in the response, as they contain important information as well.

Use nonce to match a response to its request, as explained above, and use timestampMs to check how much time has passed since you made the request and you got the response. A delayed response that arrives several hours or days after the request may suggest suspicious activity.

Use apkPackageName to check the name of the APK that made the attestation request, and match apkDigestSha256 and apkCertificateDigestSha256 to those from your app's signed APK in Google Play, to get a signal about the integrity of the installed app.

Remember that the trustworthiness of the response as a whole is tied to the results of ctsProfileMatch and basicIntegrity. It is not unthinkable for a compromised device that fails basicIntegrity to have forged the rest of the values in the response.

7. Not understanding the differences between ctsProfileMatch and basicIntegrity

The SafetyNet Attestation API initially provided a single value called basicIntegrity to help developers determine the integrity of a device. As the API evolved, we introduced a new, stricter check whose results appear in a value called ctsProfileMatch, which allows developers to more finely evaluate the devices on which their app is running.

In broad terms, basicIntegrity gives you a signal about the general integrity of the device and its API. Rooted devices fail basicIntegrity, as do emulators, virtual devices, and devices with signs of tampering, such as API hooks.

On the other hand, ctsProfileMatch gives you a much stricter signal about the compatibility of the device. Only unmodified devices that have been certified by Google can pass ctsProfileMatch. Devices that will fail ctsProfileMatch include the following:

  • Devices that fail basicIntegrity
  • Devices with an unlocked bootloader
  • Devices with a custom system image (custom ROM)
  • Devices for which the manufactured didn't apply for, or pass, Google certification
  • Devices with a system image built directly from the Android Open Source Program source files
  • Devices with a system image distributed as part of a beta or developer preview program (including the Android Beta Program)

8. Not having a strategy for timing attestation checks

The SafetyNet Attestation API gives you a snapshot of the state of a device at the moment when the attestation request was made. A successful attestation doesn't necessarily mean that the device would have passed attestation in the past, or that it will in the future.

Because an attestation is just a spot check, you should plan a sensible strategy for choosing when to make attestation requests. You may choose to require successful attestations before users make in-app purchases, after a certain number of days have passed since the last successful attestation, each time your app is launched, after every reboot, or any other strategy that makes sense for your app.

Keep in mind that an attestation request is computationally expensive, consumes battery and bandwidth, and uses your quota. We recommend you plan a strategy to use the least amount of attestations required to satisfy your use case.

9. Using the SafetyNet Attestation API results as the only signal to attack abuse

It may be tempting to think that the SafetyNet Attestation API provides all the necessary signals for protecting an app against abusers, and use it as the only signal for building an anti-abuse system.

The SafetyNet Attestation API can only give signals about the state of a device, not the intent of a user, which is what an anti-abuse system should be designed to detect. Therefore, you might want to consider including other signals, such as access logs and behavioral patterns, to more accurately detect abusive users, and consider not blocking users solely on a failed attestation. Furthermore, there are many other conditions that cause an attestation to fail, such as network connection problems, quota issues, and other transient problems.

In other words, not all users who fail attestation are necessarily abusers, and not all abusers will necessarily fail attestation. By blocking users solely on their attestation results, you might be missing abusive users that don't fail attestations. Furthermore, you might also be blocking legitimate, loyal customers who fail attestations for reasons other than abuse.

10. Not monitoring and managing your usage quota

As mentioned before, the SafetyNet Attestation API is rate limited, and there is a default quota of 10,000 requests per day for each API key. Although this quota might be enough for most development, testing, and initial app launches, your app might reach the default limit as it increases in popularity.

To prevent inadvertently reaching your quota and getting attestation errors, you should build a system that monitors your usage of the API and warns you well before you reach your quota so you can get it increased. You should also be prepared to handle attestation failures because of an exceeded quota and avoid blocking all your users in this situation.

If you are close to reaching your quota, or expect a short-term spike that may lead you to exceed your quota, you can submit this form to request short or long-term increases to the quota for your API key. This process, as well as the additional quota, is free of charge.

New research: Understanding the root cause of account takeover


Account takeover, or ‘hijacking’, is unfortunately a common problem for users across the web. More than 15% of Internet users have reported experiencing the takeover of an email or social networking account. However, despite its familiarity, there is a dearth of research about the root causes of hijacking.

With Google accounts as a case-study, we teamed up with the University of California, Berkeley to better understand how hijackers attempt to take over accounts in the wild. From March 2016 to March 2017, we analyzed several black markets to see how hijackers steal passwords and other sensitive data. We’ve highlighted some important findings from our investigation below. We presented our study at the Conference on Computer and Communications Security (CCS) and it’s now available here.

What we learned from the research proved to be immediately useful. We applied its insights to our existing protections and secured 67 million Google accounts before they were abused. We’re sharing this information publicly so that other online services can better secure their users, and can also supplement their authentication systems with more protections beyond just passwords.


How hijackers steal passwords on the black market

Our research tracked several black markets that traded third-party password breaches, as well as 25,000 blackhat tools used for phishing and keylogging. In total, these sources helped us identify 788,000 credentials stolen via keyloggers, 12 million credentials stolen via phishing, and 3.3 billion credentials exposed by third-party breaches.

While our study focused on Google, these password stealing tactics pose a risk to all account-based online services. In the case of third-party data breaches, 12% of the exposed records included a Gmail address serving as a username and a password; of those passwords, 7% were valid due to reuse. When it comes to phishing and keyloggers, attackers frequently target Google accounts to varying success: 12-25% of attacks yield a valid password.

However, because a password alone is rarely sufficient for gaining access to a Google account, increasingly sophisticated attackers also try to collect sensitive data that we may request when verifying an account holder’s identity. We found 82% of blackhat phishing tools and 74% of keyloggers attempted to collect a user’s IP address and location, while another 18% of tools collected phone numbers and device make and model.

By ranking the relative risk to users, we found that phishing posed the greatest threat, followed by keyloggers, and finally third-party breaches.

Protecting our users from account takeover

Our findings were clear: enterprising hijackers are constantly searching for, and are able to find, billions of different platforms’ usernames and passwords on black markets. While we have already applied these insights to our existing protections, our findings are yet another reminder that we must continuously evolve our defenses in order to stay ahead of these bad actors and keep users safe.

For many years, we’ve applied a ‘defense in-depth’ approach to security—a layered series of constantly improving protections that automatically prevent, detect, and mitigate threats to keep your account safe.

Prevention

A wide variety of safeguards help us to prevent attacks before they ever affect our users. For example, Safe Browsing, which now protects more than 3 billion devices, alerts users before they visit a dangerous site or when they click a link to a dangerous site within Gmail. We recently announced the Advanced Protection program which provides extra security for users that are at elevated risk of attack.

Detection

We monitor every login attempt to your account for suspicious activity. When there is a sign-in attempt from a device you’ve never used, or a location you don’t commonly access your account from, we’ll require additional information before granting access to your account. For example, if you sign in from a new laptop and you have a phone associated with you account, you will see a prompt—we’re calling these dynamic verification challenges—like this:
This challenge provides two-factor authentication on all suspicious logins, while mitigating the risk of account lockout.

Mitigation

Finally, we regularly scan activity across Google’s suite of products for suspicious actions performed by hijackers and when we find any, we lock down the affected accounts to prevent any further damage as quickly as possible. We prevent or undo actions we attribute to account takeover, notify the affected user, and help them change their password and re-secure their account into a healthy state.

What you can do

There are some simple steps you can take that make these defenses even stronger. Visit our Security Checkup to make sure you have recovery information associated with your account, like a phone number. Allow Chrome to automatically generate passwords for your accounts and save them via Smart Lock. We’re constantly working to improve these tools, and our automatic protections, to keep your data safe.

Introducing the Google Play Security Reward Program



We have long enjoyed a close relationship with the security research community. To recognize the valuable external contributions that help us keep our users safe online, we maintain reward programs for Google-developed websites and apps, for Chrome and Chrome OS, and for the latest version of Android running on Pixel devices. These programs have been a success and helped uncover hundreds of vulnerabilities, while also paying out millions of dollars to participating security researchers and research teams.

Today, we’re introducing the Google Play Security Reward Program to incentivize security research into popular Android apps available on Google Play. Through our collaboration with independent bug bounty platform, HackerOne, we’ll enable security researchers to submit an eligible vulnerability to participating developers, who are listed in the program rules. After the vulnerability is addressed, the eligible researcher submits a report to the Play Security Reward Program to receive a monetary reward from Google Play.

With the ongoing success of our other reward programs, we invite developers and the research community to work together with us on proactively improving the security of some of the most popular Android apps on Google Play.

The program is limited to a select number of developers at this time to get initial feedback. Developers can contact their Google Play partner manager to show interest. All developers will benefit when bugs are discovered because we will scan all apps for them and deliver security recommendations to the developers of any affected apps. For more information, visit the Play Security Reward Program on HackerOne.

Introducing the Google Play Security Reward Program



We have long enjoyed a close relationship with the security research community. To recognize the valuable external contributions that help us keep our users safe online, we maintain reward programs for Google-developed websites and apps, for Chrome and Chrome OS, and for the latest version of Android running on Pixel devices. These programs have been a success and helped uncover hundreds of vulnerabilities, while also paying out millions of dollars to participating security researchers and research teams.

Today, we’re introducing the Google Play Security Reward Program to incentivize security research into popular Android apps available on Google Play. Through our collaboration with independent bug bounty platform, HackerOne, we’ll enable security researchers to submit an eligible vulnerability to participating developers, who are listed in the program rules. After the vulnerability is addressed, the eligible researcher submits a report to the Play Security Reward Program to receive a monetary reward from Google Play.

With the ongoing success of our other reward programs, we invite developers and the research community to work together with us on proactively improving the security of some of the most popular Android apps on Google Play.

The program is limited to a select number of developers at this time to get initial feedback. Developers can contact their Google Play partner manager to show interest. All developers will benefit when bugs are discovered because we will scan all apps for them and deliver security recommendations to the developers of any affected apps. For more information, visit the Play Security Reward Program on HackerOne.

Behind the Masq: Yet more DNS, and DHCP, vulnerabilities



Our team has previously posted about DNS vulnerabilities and exploits. Lately, we’ve been busy reviewing the security of another DNS software package: Dnsmasq. We are writing this to disclose the issues we found and to publicize the patches in an effort to increase their uptake.

Dnsmasq provides functionality for serving DNS, DHCP, router advertisements and network boot. This software is commonly installed in systems as varied as desktop Linux distributions (like Ubuntu), home routers, and IoT devices. Dnsmasq is widely used both on the open internet and internally in private networks.

We discovered seven distinct issues (listed below) over the course of our regular internal security assessments. Once we determined the severity of these issues, we worked to investigate their impact and exploitability and then produced internal proofs of concept for each of them. We also worked with the maintainer of Dnsmasq, Simon Kelley, to produce appropriate patches and mitigate the issue.

These patches have been upstreamed and are now committed to the project’s git repository. In addition to these patches we have also submitted another patch which will run Dnsmasq under seccomp-bpf to allow for additional sandboxing. This patch has been submitted to the DNSmasq project for review and we have also made it available here for those who wish to integrate it into an existing install (after testing, of course!). We believe the adoption of this patch will increase the security of DNSMasq installations.

We would like to thank Simon Kelley for his help in patching these bugs in the core Dnsmasq codebase. Users who have deployed the latest version of Dnsmasq (2.78) will be protected from the attacks discovered here. Android partners have received this patch as well and it will be included in Android's monthly security update for October. Kubernetes versions 1.5.8, 1.6.11, 1.7.7, and 1.8.0 have been released with a patched DNS pod. Other affected Google services have been updated.

During our review, the team found three potential remote code executions, one information leak, and three denial of service vulnerabilities affecting the latest version at the project git server as of September 5th 2017.

CVE
Impact
Vector
Notes
PoC
CVE-2017-14491
RCE
DNS
Heap based overflow (2 bytes). Before 2.76 and this commit overflow was unrestricted.
CVE-2017-14492
RCE
DHCP
Heap based overflow.
CVE-2017-14493
RCE
DHCP
Stack Based overflow.
CVE-2017-14494
Information Leak
DHCP
Can help bypass ASLR.
CVE-2017-14495
OOM/DoS
DNS
Lack of free() here.
CVE-2017-14496
DoS
DNS
Invalid boundary checks here. Integer underflow leading to a huge memcpy.
CVE-2017-13704
DoS
DNS
Bug collision with CVE-2017-13704



It is worth expanding on some of these:

  • CVE-2017-14491 is a DNS-based vulnerability that affects both directly exposed and internal network setups. Although the latest git version only allows a 2-byte overflow, this could be exploited based on previous research. Before version 2.76 and this commit the overflow is unrestricted. 
==1159==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62200001dd0b at pc 0x0000005105e7 bp 0x7fff6165b9b0 sp0x7fff6165b9a8
WRITE of size 1 at 0x62200001dd0b thread T0
  #0 0x5105e6 in add_resource_record
/test/dnsmasq/src/rfc1035.c:1141:7
  #1 0x5127c8 in answer_request /test/dnsmasq/src/rfc1035.c:1428:11
  #2 0x534578 in receive_query /test/dnsmasq/src/forward.c:1439:11
  #3 0x548486 in check_dns_listeners 
/test/dnsmasq/src/dnsmasq.c:1565:2
  #4 0x5448b6 in main /test/dnsmasq/src/dnsmasq.c:1044:7
  #5 0x7fdf4b3972b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
  #6 0x41cbe9 in _start (/test/dnsmasq/src/dnsmasq+0x41cbe9)

  • CVE-2017-14493 is a trivial-to-exploit DHCP-based, stack-based buffer overflow vulnerability. In combination with CVE-2017-14494 acting as an info leak, an attacker could bypass ASLR and gain remote code execution.
dnsmasq[15714]: segfault at 1337deadbeef ip 00001337deadbeef sp 00007fff1b66fd10 error 14 in libnss_files-2.24.so[7f7cfbacb000+a000]
  • Android is affected by CVE-2017-14496 when the attacker is local or tethered directly to the device—the service itself is sandboxed so the risk is reduced. Android partners received patches on 5 September 2017 and devices with a 2017-10-01 security patch level or later address this issue.
Proofs of concept are provided so you can check if you are affected by these issues, and verify any mitigations you may deploy.


We would like to thank the following people for discovering, investigating impact/exploitability and developing PoCs: Felix Wilhelm, Fermin J. Serna, Gabriel Campana, Kevin Hamacher, Ron Bowes and Gynvael Coldwind of the Google Security Team.

Broadening HSTS to secure more of the Web


The security of the Web is of the utmost importance to Google. One of the most powerful tools in the Web security toolbox is ensuring that connections to websites are encrypted using HTTPS, which prevents Web traffic from being intercepted, altered, or misdirected in transit. We have taken many actions to make the use of HTTPS more widespread, both within Google and on the larger Internet.

We began in 2010 by defaulting to HTTPS for Gmail and starting the transition to encrypted search by default. In 2014, we started encouraging other websites to use HTTPS by giving secure sites a ranking boost in Google Search. In 2016, we became a platinum sponsor of Let’s Encrypt, a service that provides simple and free SSL certificates. Earlier this year we announced that Chrome will start displaying warnings on insecure sites, and we recently introduced fully managed SSL certificates in App Engine. And today we’re proud to announce that we are beginning to use another tool in our toolbox, the HTTPS Strict Transport Security (HSTS) preload list, in a new and more impactful way.

The HSTS preload list is built in to all major browsers (Chrome, Firefox, Safari, Internet Explorer/Edge, and Opera). It consists of a list of hostnames for which browsers automatically enforce HTTPS-secured connections. For example, gmail.com is on the list, which means that the aforementioned browsers will never make insecure connections to Gmail; if the user types http://gmail.com, the browser first changes it to https://gmail.com before sending the request. This provides greater security because the browser never loads an http-to-https redirect page, which could be intercepted.

The HSTS preload list can contain individual domains or subdomains and even top-level domains (TLDs), which are added through the HSTS website. The TLD is the last part of the domain name, e.g., .com, .net, or .org. Google operates 45 TLDs, including .google, .how, and .soy. In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.

The use of TLD-level HSTS allows such namespaces to be secure by default. Registrants receive guaranteed protection for themselves and their users simply by choosing a secure TLD for their website and configuring an SSL certificate, without having to add individual domains or subdomains to the HSTS preload list. Moreover, since it typically takes months between adding a domain name to the list and browser upgrades reaching a majority of users, using an already-secured TLD provides immediate protection rather than eventual protection. Adding an entire TLD to the HSTS preload list is also more efficient, as it secures all domains under that TLD without the overhead of having to include all those domains individually.

We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.

Safe Browsing: Protecting more than 3 billion devices worldwide, automatically



[Cross-posted from The Keyword]

In 2007, we launched Safe Browsing, one of Google’s earliest anti-malware efforts. To keep our users safe, we’d show them a warning before they visited a site that might’ve harmed their computers.
Computing has evolved a bit in the last decade, though. Smartphones created a more mobile internet, and now AI is increasingly changing how the world interacts with it. Safe Browsing also had to evolve to effectively protect users.

And it has: In May 2016, we announced that Safe Browsing was protecting more than 2 billion devices from badness on the internet. Today we’re announcing that Safe Browsing has crossed the threshold to 3 billion devices. We’re sharing a bit more about how we got here, and where we’re going.

What is Safe Browsing?

You may not know Safe Browsing by name, since most of the time we’re invisibly protecting you, without getting in the way. But you may have seen a warning like this at some point:
This notification is one of the visible parts of Safe Browsing, a collection of Google technologies that hunt badness—typically websites that deceive users—on the internet. We identify sites that might try to phish you, or sites that install malware or other undesirable software. The systems that make up Safe Browsing work together to identify, analyze and continuously keep Safe Browsing’s knowledge of the harmful parts of the internet up to date.

This protective information that we generate—a curated list of places that are dangerous for people and their devices—is used across many of our products. It helps keep search results safe and keep ads free from badness; it’s integral to Google Play Protect and keeps you safe on Android; and it helps Gmail shield you from malicious messages.

And Safe Browsing doesn’t protect only Google’s products. For many years, Safari and Firefox have protected their users with Safe Browsing as well. If you use an up-to-date version of Chrome, Firefox or Safari, you’re protected by default. Safe Browsing is also used widely by web developers and app developers (including Snapchat), who integrate our protections by checking URLs before they’re presented to their users.

Protecting more people with fewer bits

In the days when web browsers were used only on personal computers, we didn’t worry much about the amount of data Safe Browsing sent over the internet to keep your browser current. Mobile devices changed all that: Slow connections, expensive mobile data plans, and scarce battery capacity became important new considerations.

So over the last few years, we’ve rethought how Safe Browsing delivers data. We built new technologies to make its data as compact as possible: We only send the information that’s most protective to a given device, and we make sure this data is compressed as tightly as possible. (All this work benefits desktop browsers, too!)

We initially introduced our new mobile-optimized method in late 2015 with Chrome on Android, made it more broadly available in mid-2016, when we also started actively encouraging Android developers to integrate it. With the release of iOS 10 in September 2016, Safari began using our new, efficient Safe Browsing update technology, giving iOS users a protection boost.

Safe Browsing in an AI-first world

The internet is at the start of another major shift. Safe Browsing has already been using machine learning for many years to detect much badness of many kinds. We’re continually evaluating and integrating cutting-edge new approaches to improve Safe Browsing.

Protecting all users across all their platforms makes the internet safer for everyone. Wherever the future of the internet takes us, Safe Browsing will be there, continuing to evolve, expand, and protect people wherever they are.

Chrome’s Plan to Distrust Symantec Certificates



This post is a broader announcement of plans already finalized on the blink-dev mailing list.

At the end of July, the Chrome team and the PKI community converged upon a plan to reduce, and ultimately remove, trust in Symantec’s infrastructure in order to uphold users’ security and privacy when browsing the web. This plan, arrived at after significant debate on the blink-dev forum, would allow reasonable time for a transition to new, independently-operated Managed Partner Infrastructure while Symantec modernizes and redesigns its infrastructure to adhere to industry standards. This post reiterates this plan and includes a timeline detailing when site operators may need to obtain new certificates.

On January 19, 2017, a public posting to the mozilla.dev.security.policy newsgroup drew attention to a series of questionable website authentication certificates issued by Symantec Corporation’s PKI. Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements. During the subsequent investigation, it was revealed that Symantec had entrusted several organizations with the ability to issue certificates without the appropriate or necessary oversight, and had been aware of security deficiencies at these organizations for some time.

This incident, while distinct from a previous incident in 2015, was part of a continuing pattern of issues over the past several years that has caused the Chrome team to lose confidence in the trustworthiness of Symantec’s infrastructure, and as a result, the certificates that have been or will be issued from it.

After our agreed-upon proposal was circulated, Symantec announced the selection of DigiCert to run this independently-operated Managed Partner Infrastructure, as well as their intention to sell their PKI business to DigiCert in lieu of building a new trusted infrastructure. This post outlines the timeline for that transition and the steps that existing Symantec customers should take to minimize disruption to their users.

Information For Site Operators

Starting with Chrome 66, Chrome will remove trust in Symantec-issued certificates issued prior to June 1, 2016. Chrome 66 is currently scheduled to be released to Chrome Beta users on March 15, 2018 and to Chrome Stable users around April 17, 2018.

If you are a site operator with a certificate issued by a Symantec CA prior to June 1, 2016, then prior to the release of Chrome 66, you will need to replace the existing certificate with a new certificate from any Certificate Authority trusted by Chrome.

Additionally, by December 1, 2017, Symantec will transition issuance and operation of publicly-trusted certificates to DigiCert infrastructure, and certificates issued from the old Symantec infrastructure after this date will not be trusted in Chrome.

Around the week of October 23, 2018, Chrome 70 will be released, which will fully remove trust in Symantec’s old infrastructure and all of the certificates it has issued. This will affect any certificate chaining to Symantec roots, except for the small number issued by the independently-operated and audited subordinate CAs previously disclosed to Google.

Site operators that need to obtain certificates from Symantec’s existing root and intermediate certificates may do so from the old infrastructure until December 1, 2017, although these certificates will need to be replaced again prior to Chrome 70. Additionally, certificates issued from Symantec’s infrastructure will have their validity limited to 13 months. Alternatively, site operators may obtain replacement certificates from any other Certificate Authority currently trusted by Chrome, which are unaffected by this distrust or validity period limit.
Reference Timeline

The following is a timeline of relevant dates associated with this plan, which distills the various requirements and milestones into an actionable set of information for site operators. As always, Chrome release dates can vary by a number of days, but upcoming release dates can be tracked here.

Date
Event
Now
through
~March 15, 2018
Site Operators using Symantec-issued TLS server certificates issued before June 1, 2016 should replace these certificates. These certificates can be replaced by any currently trusted CA.
~October 24, 2017
Chrome 62 released to Stable, which will add alerting in DevTools when evaluating certificates that will be affected by the Chrome 66 distrust.
December 1, 2017
According to Symantec, DigiCert’s new “Managed Partner Infrastructure” will at this point be capable of full issuance. Any certificates issued by Symantec’s old infrastructure after this point will cease working in a future Chrome update.

From this date forward, Site Operators can obtain TLS server certificates from the new Managed Partner Infrastructure that will continue to be trusted after Chrome 70 (~October 23, 2018).

December 1, 2017 does not mandate any certificate changes, but represents an opportunity for site operators to obtain TLS server certificates that will not be affected by Chrome 70’s distrust of the old infrastructure.
~March 15, 2018
Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66.

Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.
~April 17, 2018
Chrome 66 released to Stable.
~September 13, 2018
Chrome 70 released to Beta, which will remove trust in the old Symantec-rooted Infrastructure. This will not affect any certificate chaining to the new Managed Partner Infrastructure, which Symantec has said will be operational by December 1, 2017.

Only TLS server certificates issued by Symantec’s old infrastructure will be affected by this distrust regardless of issuance date.
~October 23, 2018
Chrome 70 released to Stable.

Hardening the Kernel in Android Oreo

Posted by Sami Tolvanen, Senior Software Engineer, Android Security

The hardening of Android's userspace has increasingly made the underlying Linux kernel a more attractive target to attackers. As a result, more than a third of Android security bugs were found in the kernel last year. In Android 8.0 (Oreo), significant effort has gone into hardening the kernel to reduce the number and impact of security bugs.

Android Nougat worked to protect the kernel by isolating it from userspace processes with the addition of SELinux ioctl filtering and requiring seccomp-bpf support, which allows apps to filter access to available system calls when processing untrusted input. Android 8.0 focuses on kernel self-protection with four security-hardening features backported from upstream Linux to all Android kernels supported in devices that first ship with this release.

Hardened usercopy

Usercopy functions are used by the kernel to transfer data from user space to kernel space memory and back again. Since 2014, missing or invalid bounds checking has caused about 45% of Android's kernel vulnerabilities. Hardened usercopy adds bounds checking to usercopy functions, which helps developers spot misuse and fix bugs in their code. Also, if obscure driver bugs slip through, hardening these functions prevents the exploitation of such bugs.

This feature was introduced in the upstream kernel version 4.8, and we have backported it to Android kernels 3.18 and above.

int buggy_driver_function(void __user *src, size_t size)
{
    /* potential size_t overflow (don’t do this) */
    u8 *buf = kmalloc(size * N, GPF_KERNEL);
    …
    /* results in buf smaller than size, and a heap overflow */
    if (copy_from_user(buf, src, size))
    return -EFAULT;

    /* never reached with CONFIG_HARDENED_USERCOPY=y */
}

An example of a security issue that hardened usercopy prevents.

Privileged Access Never (PAN) emulation

While hardened usercopy functions help find and mitigate security issues, they can only help if developers actually use them. Currently, all kernel code, including drivers, can access user space memory directly, which can lead to various security issues.

To mitigate this, CPU vendors have introduced features such as Supervisor Mode Access Prevention (SMAP) in x86 and Privileged Access Never (PAN) in ARM v8.1. These features prevent the kernel from accessing user space directly and ensure developers go through usercopy functions. Unfortunately, these hardware features are not yet widely available in devices that most Android users have today.

Upstream Linux introduced software emulation for PAN in kernel version 4.3 for ARM and 4.10 in ARM64. We have backported both features to Android kernels starting from 3.18.

Together with hardened usercopy, PAN emulation has helped find and fix bugs in four kernel drivers in Pixel devices.

int buggy_driver_copy_data(struct mydata *src, void __user *ptr)
{
    /* failure to keep track of user space pointers */
    struct mydata *dst = (struct mydata *)ptr;
    …
    /* read/write from/to an arbitrary user space memory location */
    dst->field = … ;    /* use copy_(from|to)_user instead! */
    …
    /* never reached with PAN (emulation) or SMAP */
}

An example of a security issue that PAN emulation mitigates.

Kernel Address Space Layout Randomization (KASLR)

Android has included support for Address Space Layout Randomization (ASLR) for years. Randomizing memory layout makes code reuse attacks probabilistic and therefore more difficult for an attacker to exploit, especially remotely. Android 8.0 brings this feature to the kernel. While Linux has supported KASLR on x86 since version 3.14, KASLR for ARM64 has only been available upstream since Linux 4.6. Android 8.0 makes KASLR available in Android kernels 4.4 and newer.

KASLR helps mitigate kernel vulnerabilities by randomizing the location where kernel code is loaded on each boot. On ARM64, for example, it adds 13–25 bits of entropy depending on the memory configuration of the device, which makes code reuse attacks more difficult.

Post-init read-only memory

The final hardening feature extends existing memory protections in the kernel by creating a memory region that's marked read-only after the kernel has been initialized. This makes it possible for developers to improve protection on data that needs to be writable during initialization, but shouldn't be modified after that. Having less writable memory reduces the internal attack surface of the kernel, making exploitation harder.

Post-init read-only memory was introduced in upstream kernel version 4.6 and we have backported it to Android kernels 3.18 and newer. While we have applied these protections to some data structures in the core kernel, this feature is extremely useful for developers working on kernel drivers.

Conclusion

Android Oreo includes mitigations for the most common source of security bugs in the kernel. This is especially relevant because 85% of kernel security bugs in Android have been in vendor drivers that tend to get much less scrutiny. These updates make it easier for driver developers to discover common bugs during development, stopping them before they can reach end user devices.