Google Online Security Blog

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.

PHA Family Highlights: Zen and its cousins

January 11, 2019

table, th, td { border: 1px solid black; Posted by Lukasz Siewierski, Android Security & Privacy TeamGoogle Play ProtectPotentially Harmful Applicationsmachine learningZen Background Apps with a custom-made advertisement SDK

Click fraud apps{ "data": [{ "id": "107", "url": "<ayud_url>", "click_type": "2", "keywords_js": [{ "keyword": "<a class=\"show_hide btnnext\"", "js": "javascript:window:document.getElementsByClassName(\"show_hide btnnext\")[0].click();", { "keyword": "value=\"Subscribe\" id=\"sub-click\"", "js": "javascript:window:document.getElementById(\"sub-click\").click();"show_hide btnnextclick() Rooting trojansVerified Bootstatistics() The Zen trojanenabled_accessibility_servicesif (!title.containsKey("Enter the code")) { if (!title.containsKey("Basic information")) { if (!title.containsKey(new String(android.util.Base64.decode("SG93IHlvdeKAmWxsIHNpZ24gaW4=".getBytes(), 0)))) { if (!title.containsKey("Create password")) { if (!title.containsKey("Add phone number")) {

system_serversystem_serverLmt_INJECTSELinux protection

The source process checks the mapping between a process id and a process name. This is done by reading the /proc/[pid]/cmdline file.
This very first step fails in Android 7.0 and higher, even with a root permission. The /proc filesystem is now mounted with a hidepid=2 parameter, which means that the process cannot access other process /proc/[pid] directory.

A ptrace_attach syscall is called. This allows the source process to trace the target.

The source process looks at its own memory to calculate the offset between the beginning of the libc library and the mmap address.

The source process reads /proc/[pid]/maps to find where libc is located in the target process memory. By adding the previously calculated offset, it can get the address of the mmap function in the target process memory.

The source process tries to determine the location of dlopen, dlsym, and dlclose functions in the target process. It uses the same technique as it used to determine the offset to the mmap function.

The source process writes the native shellcode into the memory region allocated by mmap. Additionally, it also writes addresses of dlopen, dlsym, and dlclose into the same region, so that they can be used by the shellcode. Shellcode simply uses dlopen to open a .so file within the target process and then dlsym to find a symbol in that file and run it.

The source process changes the registers in the target process so that PC register points directly to the shellcode. This is done using the ptrace syscall.

Summary

Open your Android device's Google Play Store app.

Tap Menu>Play Protect.

Look for information about the status of your device.

Hashes of samples

Type

Package name

SHA256 digest

Custom ads

com.targetshoot.zombieapocalypse.sniper.zombieshootinggame

5d98d8a7a012a858f0fa4cf8d2ed3d5a82937b1a98ea2703d440307c63c6c928

Click fraud

com.counterterrorist.cs.elite.combat.shootinggame

84672fb2f228ec749d3c3c1cb168a1c31f544970fd29136bea2a5b2cefac6d04

Rooting trojan

com.android.world.news

bd233c1f5c477b0cc15d7f84392dab3a7a598243efa3154304327ff4580ae213

Zen trojan

com.lmt.register

eb12cd65589cbc6f9d3563576c304273cb6a78072b0c20a155a0951370476d8d

Google Public DNS now supports DNS-over-TLS

January 9, 2019

Posted by Marshall Vale, Product Manager and Puneet Sood, Software Engineerover eight years agoDNS-over-TLS protocolTLSthe RFC 7766 recommendationsTLS 1.3Use DNS-over-TLS today
documentationstubbydnsprivacy.orgcreate an issue on our trackerdiscussion group

Android Pie à la mode: Security & Privacy

December 20, 2018

[Cross-posted from the Android Developers Blog]

Platform hardeningFile-Based Encryptionmetadata encryptionBiometricPrompt APIApplication SandboxSELinuxAnti-exploitation improvementscompiler-based security mitigationsControl Flow Integrity (CFI)CFI in the Android common kernelInteger Overflow SanitizationContinued investment in hardware-backed securityAndroid Protected ConfirmationStrongBox Keymasterblog postrelease notesEnhancing user privacybehavior changesMAC address randomizationan attacker would not be able to access a user's backed-up application dataTLS by defaultDNS over TLSincreasing exploit difficultyindependent mobile security ratingsAcknowledgements: This post leveraged contributions from Chad Brubaker, Janis Danisevskis, Giles Hogben, Troy Kensinger, Ivan Lozano, Vishwath Mohan, Frank Salim, Sami Tolvanen, Lilian Young, and Shawn Willden.

Security Blog

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

PHA Family Highlights: Zen and its cousins

Google Public DNS now supports DNS-over-TLS

Android Pie à la mode: Security & Privacy

Labels

Archive

Feed

Company-wide

Products

Developers