Google Online Security Blog

Android Security & Privacy Year in Review 2018: Keeping two billion users, and their data, safe and sound

March 29, 2019

Posted by Meghan Kelly, Android Security & Privacy Team2018 Android Security and Privacy Year in ReviewTransparency ReportsAndroid Security Center

New features in Google Play Protect

Ecosystem and Potentially Harmful Application family highlights

Updates on our vulnerability rewards program

Platform security enhancements

Managed Google Play earns key certifications for security and privacy

March 21, 2019

Posted by Mike Burr, Android Enterprise Platform Specialist[Cross-posted from the Android Enterprise Keyword Blog]

managed Google Play StoreInternational Organization for StandardizationAmerican Institute of Certified Public AccountantsMeeting a high bar of security management standardsSecure data managementOur ongoing commitment to enterprise security

Open-sourcing Sandboxed API

March 18, 2019

Posted by Christian Blichmann & Robert Swiecki, ISE Sandboxing team

memory corruption bugspath traversalsandboxingremote code executionSandbox once, use anywhereSandboxed APISandbox2Overview

The resulting API of the SAPI object is similar to the one of the original library. For example, when using zlib, the popular compression library, a code snippet like this compresses a chunk of data (error handling omitted for brevity):
void Compress(const std::string& chunk, std::string* out) { z_stream zst{}; constexpr char kZlibVersion[] = "1.2.11"; CHECK(deflateInit_(&zst, /*level=*/4, kZlibVersion, sizeof(zst)) == Z_OK);
zst.avail_in = chunk.size(); zst.next_in = reinterpret_cast<uint8_t*>(&chunk[0]); zst.avail_out = out->size(); zst.next_out = reinterpret_cast<uint8_t*>(&(*out)[0]); CHECK(deflate(&zst, Z_FINISH) != Z_STREAM_ERROR); out->resize(zst.avail_out);
deflateEnd(&zst); }
Using Sandboxed API, this becomes: void CompressSapi(const std::string& chunk, std::string* out) { sapi::Sandbox sandbox(sapi::zlib::zlib_sapi_embed_create()); CHECK(sandbox.Init().ok()); sapi::zlib::ZlibApi api(&sandbox);
sapi::v::Array<uint8_t> s_chunk(&chunk[0], chunk.size()); sapi::v::Array<uint8_t> s_out(&(*out)[0], out->size()); CHECK(sandbox.Allocate(&s_chunk).ok() && sandbox.Allocate(&s_out).ok()); sapi::v::Struct<sapi::zlib::z_stream> s_zst; constexpr char kZlibVersion[] = "1.2.11"; sapi::v::Array<char> s_version(kZlibVersion, ABSL_ARRAYSIZE(kZlibVersion)); CHECK(api.deflateInit_(s_zst.PtrBoth(), /*level=*/4, s_version.PtrBefore(), sizeof(sapi::zlib::z_stream).ValueOrDie() == Z_OK));
CHECK(sandbox.TransferToSandboxee(&s_chunk).ok()); s_zst.mutable_data()->avail_in = chunk.size(); s_zst.mutable_data()->next_in = reinterpet_cast<uint8_t*>(s_chunk.GetRemote()); s_zst.mutable_data()->avail_out = out->size(); s_zst.mutable_data()->next_out = reinterpret_cast<uint8_t*>(s_out.GetRemote()); CHECK(api.deflate(s_zst.PtrBoth(), Z_FINISH).ValueOrDie() != Z_STREAM_ERROR); CHECK(sandbox.TransferFromSandboxee(&s_out).ok()); out->resize(s_zst.data().avail_out);
CHECK(api.deflateEnd(s_zst.PtrBoth()).ok()); }Try for yourself
Bazel sudo apt-get install python-typing python-clang-7 libclang-7-dev linux-libc-dev git clone github.com/google/sandboxed-api && cd sandboxed-api bazel test //sandboxed_api/examples/stringop:main_stringopGetting Startedexamples for Sandboxed APIWhere do we go from here?

Support more operating systems - So far, only Linux is supported. We will look into bringing Sandboxed API to the Unix-like systems like the BSDs (FreeBSD, OpenBSD) and macOS. A Windows port is a bigger undertaking and will require some more groundwork to be done.

New sandboxing technologies - With things like hardware-virtualization becoming almost ubiquitous, confining code into VMs for sandboxing opens up new possibilities.

Build system - Right now, we are using Bazel to build everything, including dependencies. We acknowledge that this is not how everyone will want to use it, so CMake support is high on our priority list.

Spread the word - Use Sandboxed API to secure open source projects. If you want to get involved, this work is also eligible for the Patch Reward Program.

Get involved
We are constantly looking at improving Sandboxed API and Sandbox2 as well as adding more features: supporting more programming runtimes, different operating systems or alternative containment technologies.
Check out the Sandboxed API GitHub repository. We will be happy to consider your contributions and look forward to any suggestions to help improve and extend this code.

Disclosing vulnerabilities to protect users across platforms

March 7, 2019

Posted by Clement Lecigne, Threat Analysis Groupupdateupdated Chromewin32k!MNGetpItemFromIndexNtUserMNDragOver()vulnerability disclosure policy

Android Security Improvement update: Helping developers harden their apps, one thwarted vulnerability at a time

February 28, 2019

Posted by Patrick Mutchler and Meghan Kelly, Android Security & Privacy Team[Cross-posted from the Android Developers Blog] Helping Android app developers build secure apps, free of known vulnerabilities, means helping the overall ecosystem thrive. This is why we launched the Application Security Improvement Program five years ago, and why we're still so invested in its success today. What the Android Security Improvement Program does When an app is submitted to the Google Play store, we scan it to determine if a variety of vulnerabilities are present. If we find something concerning, we flag it to the developer and then help them to remedy the situation.

Think of it like a routine physical. If there are no problems, the app runs through our normal tests and continues on the process to being published in the Play Store. If there is a problem, however, we provide a diagnosis and next steps to get back to healthy form. Over its lifetime, the program has helped more than 300,000 developers to fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users with the same security issues present, which we consider a win. What vulnerabilities are covered The App Security Improvement program covers a broad range of security issues in Android apps. These can be as specific as security issues in certain versions of popular libraries (ex: CVE-2015-5256) and as broad as unsafe TLS/SSL certificate validation. We are continuously improving this program's capabilities by improving the existing checks and launching checks for more classes of security vulnerability. In 2018, we deployed warnings for six additional security vulnerability classes including:

SQL Injection

File-based Cross-Site Scripting

Cross-App Scripting

Leaked Third-Party Credentials

Scheme Hijacking

JavaScript Interface Injection

Ensuring that we're continuing to evolve the program as new exploits emerge is a top priority for us. We are continuing to work on this throughout 2019. Keeping Android users safe is important to Google. We know that app security is often tricky and that developers can make mistakes. We hope to see this program grow in the years to come, helping developers worldwide build apps users can truly trust.

Google Play Protect in 2018: New updates to keep Android users secure

February 26, 2019

Posted by Rahul Mishra and Tom Watkins, Android Security & Privacy Team [Cross-posted from the Android Developers Blog]

Google Play Protect, a refresher potentially harmful applications What's newOn by default

New and rare appsContext is everything: warning users on launch

Auto-disabling apps policiesAcknowledgements: This post leveraged contributions from Meghan Kelly and William Luh.

How we fought bad apps and malicious developers in 2018

February 13, 2019

Posted by Andrew Ahn, Product Manager, Google Play[Cross-posted from the Android Developers Blog]

Google Play Protect

Protecting User Privacyannounced

Developer integrity

Harmful app contents and behaviorsblog postPotentially Harmful Applications How useful did you find this blog post?
★ ★ ★ ★ ★

Open sourcing ClusterFuzz

February 7, 2019

Posted by Abhishek Arya, Oliver Chang, Max Moroz, Martin Barbella and Jonathan Metzman (ClusterFuzz team)[Cross-posted from the Google Open-Source Blog]Fuzzingmemory corruption bugsserioussecurityimplicationsunsafeprovide these featuresOSS-FuzzClusterFuzz

bisection16,00011,000160bugsGitHub repositoryinstructionsproductionGoogle Cloud Platform

Introducing Adiantum: Encryption for the Next Billion Users

February 7, 2019

Posted by Paul Crowley and Eric Biggers, Android Security & Privacy Team

allAndroid Gosmart watchesTVsrequiredChaCha20 stream cipherin 2014 Google selected ChaCha20Poly1305 authenticatorRFC7539noncemessage integrityAdiantumHCTRHCH

Additional resourcesAdiantum: length-preserving encryption for entry-level processorsAndroid common kernels v4.9 and highermainline Linux kernel v5.0 and higherhttps://github.com/google/adiantumenable AdiantumAndroid Compatibility Definition DocumentAcknowledgements: This post leveraged contributions from Greg Kaiser and Luke Haviland. Adiantum was designed by Paul Crowley and Eric Biggers, implemented in Android by Eric Biggers and Greg Kaiser, and named by Danielle Roberts.

Protect your accounts from data breaches with Password Checkup

February 5, 2019

Posted by Jennifer Pullman, Kurt Thomas, and Elie Bursztein, Security and Anti-abuse researchUpdate (Feb 6)prevention, detection, and mitigationthird-party data breachesten times the riskPassword Checkup Chrome extension

Key design principles

Alerts are actionable, not informational: We believe that an alert should provide concise and accurate security advice. For an unsafe account, that means resetting your password. While it’s possible for data breaches to expose other personal data such as a phone number or mailing address, there’s no straightforward next step to re-securing that data. That’s why we focus only on warning you about unsafe usernames and passwords.

Privacy is at the heart of our design: Your usernames and passwords are incredibly sensitive. We designed Password Checkup with privacy-preserving technologies to never reveal this personal information to Google. We also designed Password Checkup to prevent an attacker from abusing Password Checkup to reveal unsafe usernames and passwords. Finally, all statistics reported by the extension are anonymous. These metrics include the number of lookups that surface an unsafe credential, whether an alert leads to a password change, and the web domain involved for improving site compatibility.

Advice that avoids fatigue: We designed Password Checkup to only alert you when all of the information necessary to access your account has fallen into the hands of an attacker. We won’t bother you about outdated passwords you’ve already reset or merely weak passwords like “123456”. We only generate an alert when both your current username and password appear in a breach, as that poses the greatest risk.

Settling on an approach
At a high level, Password Checkup needs to query Google about the breach status of a username and password without revealing the information queried. At the same time, we need to ensure that no information about other unsafe usernames or passwords leaks in the process, and that brute force guessing is not an option. Password Checkup addresses all of these requirements by using multiple rounds of hashing, k-anonymity, and private set intersection with blinding.
Our approach strikes a balance between privacy, computation overhead, and network latency. While single-party private information retrieval (PIR) and 1-out-of-N oblivious transfer solve some of our requirements, the communication overhead involved for a database of over 4 billion records is presently intractable. Alternatively, k-party PIR and hardware enclaves present efficient alternatives, but they require user trust in schemes that are not widely deployed yet in practice. For k-party PIR, there is a risk of collusion; for enclaves, there is a risk of hardware vulnerabilities and side-channels.
A look under the hood
Here’s how Password Checkup works in practice to satisfy our security and privacy requirements.

Protecting your accounts
Password Checkup is currently available as an extension for Chrome. Since this is a first version, we will continue refining it over the coming months, including improving site compatibility and username and password field detection.
Acknowledgements
This post reflects the work of a large group of Google engineers, research scientists, and others including: Niti Arora, Jacob Barrett, Borbala Benko, Alan Butler, Abhi Chaudhuri, Oxana Comanescu, Sunny Consolvo, Michael Dedrick, Kyler Emig, Mihaela Ion, Ilona Gaweda, Luca Invernizzi, Jozef Janovský, Yu Jiang, Patrick Gage Kelly, Nirdhar Khazanie, Guemmy Kim, Ben Kreuter, Valentina Lapteva, Maija Marincenko, Grzegorz Milka, Angelika Moscicki, Julia Nalven, Yuan Niu, Sarvar Patel, Tadek Pietraszek, Ganbayar Puntsagdash, Ananth Raghunathan, Juri Ranieri, Mark Risher, Masaru Sato, Karn Seth, Juho Snellman, Eduardo Tejada, Tu Tsao, Andy Wen, Kevin Yeo, Moti Yung, and Ali Zand.

Mar	APR	May
	04
2018	2019	2020

Security Blog

Android Security & Privacy Year in Review 2018: Keeping two billion users, and their data, safe and sound

Managed Google Play earns key certifications for security and privacy

Open-sourcing Sandboxed API

Disclosing vulnerabilities to protect users across platforms

Android Security Improvement update: Helping developers harden their apps, one thwarted vulnerability at a time

Google Play Protect in 2018: New updates to keep Android users secure

How we fought bad apps and malicious developers in 2018

Open sourcing ClusterFuzz

Introducing Adiantum: Encryption for the Next Billion Users

Protect your accounts from data breaches with Password Checkup

Labels

Archive

Feed

Company-wide

Products

Developers