Google Online Security Blog

Better protection against Man in the Middle phishing attacks

April 18, 2019

Posted by Jonathan Skelker, Product Manager, Account SecurityJavaScript to be enabledSafe Browsing warningsGmail spam filtersaccount sign-in challengesman in the middleChromium Embedded Frameworkrestriction on webviewWhat developers need to know
browser-based OAuth authentication

The Android Platform Security Model

April 18, 2019

Posted by Jeff Vander Stoep, Android Security & Privacy Team

demonstrateseffectivenesstheseimprovementsThe Android Platform Security Model

The security model which has implicitly informed the Android platform’s security design from the beginning, but has not been formally published or described outside of Google.

The context in which this security model must operate, including the scale of the Android ecosystem and its many form factors and use cases.

The complex threat model Android must address.

How Android’s reference implementation in the Android Open Source Project (AOSP) enacts the security model.

How Android’s security systems have evolved over time to address the threat model.

1Acknowledgements: This post leveraged contributions from René Mayrhofer, Chad Brubaker, and Nick Kralevich Notes

The term ‘consent’ here and in the paper is used to refer to various technical methods of declaring or enforcing a party’s intent, rather than the legal requirement or standard found in many privacy legal regimes around the world. ↩

Gmail making email more secure with MTA-STS standard

April 10, 2019

Posted by Nicolas Lidzborski, Senior Staff Software Engineer, Google Cloud and Nicolas Kardas, Senior Product Manager, Google Cloud SMTP MTA Strict Transport Security (MTA-STS) RFC 8461SMTP TLS Reporting RFC 8460IETFSMTP alone is vulnerable to man-in-the-middle attacks
research published in November 2015MTA-STS uses encryption and authentication to reduce vulnerabilities
Gmail is starting MTA-STS adherence. We hope others will follow
how to set up an MTA-STS policy with your DNS server

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.