Google Security Blog

Syndikovat obsah
The latest news and insights from Google on security and safety on the Internet.
Aktualizace: 34 min 44 sek zpět

Open-sourcing Sandboxed API

18 Březen, 2019 - 20:20
Posted by Christian Blichmann & Robert Swiecki, ISE Sandboxing team

Many software projects process data which is externally generated, and thus potentially untrusted. For example, this could be the conversion of user-provided picture files into different formats, or even executing user-generated software code.
When a software library parsing such data is sufficiently complex, it might fall victim to certain types of security vulnerabilities: memory corruption bugs or certain other types of problems related to the parsing logic (e.g. path traversal issues). Those vulnerabilities can have serious security implications.

In order to mitigate those problems, developers frequently employ software isolation methods, a process commonly referred to as sandboxing. By using sandboxing methods, developers make sure that only resources (files, networking connections and other operating system resources) which are deemed necessary are accessible to the code involved in parsing user-generated content. In the worst-case scenario, when potential attackers gain remote code execution rights within the scope of a software project, a sandboxing technique can contain them, protecting the rest of the software infrastructure.

Sandboxing techniques must be highly resistant to attacks and sufficiently protect the rest of the operating system, yet must be sufficiently easy-to-use for software developers. Many popular software containment tools might not sufficiently isolate the rest of the OS, and those which do, might require time-consuming redefinition of security boundaries for each and every project that should be sandboxed.

Sandbox once, use anywhere

To help with this task, we are open-sourcing our battle-tested project called Sandboxed API. Sandboxed API makes it possible to create security policies for individual software libraries. This concept allows to create reusable and secure implementations of functionality residing within popular software libraries, yet is granular enough to protect the rest of used software infrastructure.

As Sandboxed API serves the purpose of accessing individual software functions inside a sandboxed library, we are also making publicly available our core sandboxing project, Sandbox2. This is now part of Sandboxed API and provides the underlying sandboxing primitives. It can be also used standalone to isolate arbitrary Linux processes, but is considered a lower-level API.

Overview

Sandboxed API is currently implemented for software libraries written in the C programming language (or providing C bindings), though we might add support for more programming runtimes in the future.

From a high-level perspective, Sandboxed API separates the library to be sandboxed and its callers into two separate OS processes: the host binary and the sandboxee. Actual library calls are then marshalled by an API object on the host side and send via interprocess communication to the sandboxee where an RPC stub unmarshals and forwards calls to the original library.

Both the API object (SAPI object) and the RPC stub are provided by the project, with the former being auto-generated by an interface generator. Users just need to provide a sandbox policy, a set of system calls that the underlying library is allowed to make, as well as the resources it is allowed to access and use. Once ready, a library based on sandboxed API can easily be reused in other projects.

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());}As you can see, when using Sandboxed API there is extra code for setting up the sandbox itself and for transferring memory to and from the sandboxee, but other than that, the code flow stays the same.

Try for yourself

It only takes a few moments to get up and running with Sandboxed API. If Bazel is installed:
sudo apt-get install python-typing python-clang-7 libclang-7-dev linux-libc-devgit clone github.com/google/sandboxed-api && cd sandboxed-apibazel test //sandboxed_api/examples/stringop:main_stringopThis will download the necessary dependencies and run the project through its paces. More detailed instructions can be found in our Getting Started guide and be sure to check out the examples for Sandboxed API.

Where do we go from here?

Sandboxed API and Sandbox2 are used by many teams at Google. While the project is mature, we do have plans for the future beyond just maintaining it:

  • 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.
Kategorie: Hacking & Security

Disclosing vulnerabilities to protect users across platforms

7 Březen, 2019 - 21:30
Posted by Clement Lecigne, Threat Analysis Group

On Wednesday, February 27th, we reported two 0-day vulnerabilities — previously publicly-unknown vulnerabilities — one affecting Google Chrome and another in Microsoft Windows that were being exploited together.

To remediate the Chrome vulnerability (CVE-2019-5786), Google released an update for all Chrome platforms on March 1; this update was pushed through Chrome auto-update. We encourage users to verify that Chrome auto-update has already updated Chrome to 72.0.3626.121 or later.

The second vulnerability was in Microsoft Windows. It is a local privilege escalation in the Windows win32k.sys kernel driver that can be used as a security sandbox escape. The vulnerability is a NULL pointer dereference in win32k!MNGetpItemFromIndex when NtUserMNDragOver() system call is called under specific circumstances.

We strongly believe this vulnerability may only be exploitable on Windows 7 due to recent exploit mitigations added in newer versions of Windows. To date, we have only observed active exploitation against Windows 7 32-bit systems.

Pursuant to Google’s vulnerability disclosure policy, when we discovered the vulnerability we reported it to Microsoft. Today, also in compliance with our policy, we are publicly disclosing its existence, because it is a serious vulnerability in Windows that we know was being actively exploited in targeted attacks. The unpatched Windows vulnerability can still be used to elevate privileges or combined with another browser vulnerability to evade security sandboxes. Microsoft have told us they are working on a fix.

As mitigation advice for this vulnerability users should consider upgrading to Windows 10 if they are still running an older version of Windows, and to apply Windows patches from Microsoft when they become available. We will update this post when they are available.
Kategorie: Hacking & Security

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

28 Únor, 2019 - 19:36

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:

  1. SQL Injection
  2. File-based Cross-Site Scripting
  3. Cross-App Scripting
  4. Leaked Third-Party Credentials
  5. Scheme Hijacking
  6. 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.

Kategorie: Hacking & Security

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

26 Únor, 2019 - 20:00

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

In 2018, Google Play Protect made Android devices running Google Play some of the most secure smartphones available, scanning over 50 billion apps everyday for harmful behaviour.
Android devices can genuinely improve people's lives through our accessibility features, Google Assistant, digital wellbeing, Family Link, and more — but we can only do this if they are safe and secure enough to earn users' long term trust. This is Google Play Protect's charter and we're encouraged by this past year's advancements.
Google Play Protect, a refresherGoogle Play Protect is the technology we use to ensure that any device shipping with the Google Play Store is secured against potentially harmful applications (PHA). It is made up of a giant backend scanning engine to aid our analysts in sourcing and vetting applications made available on the Play Store, and built-in protection that scans apps on users' devices, immobilizing PHA and warning users.
This technology protects over 2 billion devices in the Android ecosystem every day.
What's newOn by default
We strongly believe that security should be a built-in feature of every device, not something a user needs to find and enable. When security features function at their best, most users do not need to be aware of them. To this end, we are pleased to announce that Google Play Protect is now enabled by default to secure all new devices, right out of the box. The user is notified that Google Play Protect is running, and has the option to turn it off whenever desired.

New and rare apps
Android is deployed in many diverse ways across many different users. We know that the ecosystem would not be as powerful and vibrant as it is today without an equally diverse array of apps to choose from. But installing new apps, especially from unknown sources, can carry risk.
Last year we launched a new feature that notifies users when they are installing new or rare apps that are rarely installed in the ecosystem. In these scenarios, the feature shows a warning, giving users pause to consider whether they want to trust this app, and advising them to take additional care and check the source of installation. Once Google has fully analyzed the app and determined that it is not harmful, the notification will no longer display. In 2018, this warning showed around 100,000 times per day
Context is everything: warning users on launch
It's easy to misunderstand alerts when presented out of context. We're trained to click through notifications without reading them and get back to what we were doing as quickly as possible. We know that providing timely and context-sensitive alerts to users is critical for them to be of value. We recently enabled a security feature first introduced in Android Oreo which warns users when they are about to launch a potentially harmful app on their device.

This new warning dialog provides in-context information about which app the user is about to launch, why we think it may be harmful and what might happen if they open the app. We also provide clear guidance on what to do next. These in-context dialogs ensure users are protected even if they accidentally missed an alert.
Auto-disabling apps
Google Play Protect has long been able to disable the most harmful categories of apps on users devices automatically, providing robust protection where we believe harm will be done.
In 2018, we extended this coverage to apps installed from Play that were later found to have violated Google Play's policies, e.g. on privacy, deceptive behavior or content. These apps have been suspended and removed from the Google Play Store.
This does not remove the app from user device, but it does notify the user and prevents them from opening the app accidentally. The notification gives the option to remove the app entirely.
Keeping the Android ecosystem secure is no easy task, but we firmly believe that Google Play Protect is an important security layer that's used to protect users devices and their data while maintaining the freedom, diversity and openness that makes Android, well, Android.
Acknowledgements: This post leveraged contributions from Meghan Kelly and William Luh.
Kategorie: Hacking & Security

Android Pie à la mode: Security & Privacy

22 Únor, 2019 - 20:39
Posted by Vikrant Nanda and René Mayrhofer, Android Security & Privacy Team

[Cross-posted from the Android Developers Blog]


There is no better time to talk about Android dessert releases than the holidays because who doesn't love dessert? And what is one of our favorite desserts during the holiday season? Well, pie of course.

In all seriousness, pie is a great analogy because of how the various ingredients turn into multiple layers of goodness: right from the software crust on top to the hardware layer at the bottom. Read on for a summary of security and privacy features introduced in Android Pie this year.
Platform hardening
With Android Pie, we updated File-Based Encryption to support external storage media (such as, expandable storage cards). We also introduced support for metadata encryption where hardware support is present. With filesystem metadata encryption, a single key present at boot time encrypts whatever content is not encrypted by file-based encryption (such as, directory layouts, file sizes, permissions, and creation/modification times).

Android Pie also introduced a BiometricPrompt API that apps can use to provide biometric authentication dialogs (such as, fingerprint prompt) on a device in a modality-agnostic fashion. This functionality creates a standardized look, feel, and placement for the dialog. This kind of standardization gives users more confidence that they're authenticating against a trusted biometric credential checker.

New protections and test cases for the Application Sandbox help ensure all non-privileged apps targeting Android Pie (and all future releases of Android) run in stronger SELinux sandboxes. By providing per-app cryptographic authentication to the sandbox, this protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data widely accessible.
Anti-exploitation improvements
With Android Pie, we expanded our compiler-based security mitigations, which instrument runtime operations to fail safely when undefined behavior occurs.

Control Flow Integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of compiled code. In Android Pie, it has been enabled by default within the media frameworks and other security-critical components, such as for Near Field Communication (NFC) and Bluetooth protocols. We also implemented support for CFI in the Android common kernel, continuing our efforts to harden the kernel in previous Android releases.

Integer Overflow Sanitization is a security technique used to mitigate memory corruption and information disclosure vulnerabilities caused by integer operations. We've expanded our use of Integer Overflow sanitizers by enabling their use in libraries where complex untrusted input is processed or where security vulnerabilities have been reported.
Continued investment in hardware-backed security

One of the highlights of Android Pie is Android Protected Confirmation, the first major mobile OS API that leverages a hardware-protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. Developers can use this API to display a trusted UI prompt to the user, requesting approval via a physical protected input (such as, a button on the device). The resulting cryptographically signed statement allows the relying party to reaffirm that the user would like to complete a sensitive transaction through their app.

We also introduced support for a new Keystore type that provides stronger protection for private keys by leveraging tamper-resistant hardware with dedicated CPU, RAM, and flash memory. StrongBox Keymaster is an implementation of the Keymaster hardware abstraction layer (HAL) that resides in a hardware security module. This module is designed and required to have its own processor, secure storage, True Random Number Generator (TRNG), side-channel resistance, and tamper-resistant packaging.

Other Keystore features (as part of Keymaster 4) include Keyguard-bound keys, Secure Key Import, 3DES support, and version binding. Keyguard-bound keys enable use restriction so as to protect sensitive information. Secure Key Import facilitates secure key use while protecting key material from the application or operating system. You can read more about these features in our recent blog post as well as the accompanying release notes.
Enhancing user privacy

User privacy has been boosted with several behavior changes, such as limiting the access background apps have to the camera, microphone, and device sensors. New permission rules and permission groups have been created for phone calls, phone state, and Wi-Fi scans, as well as restrictions around information retrieved from Wi-Fi scans. We have also added associated MAC address randomization, so that a device can use a different network address when connecting to a Wi-Fi network.

On top of that, Android Pie added support for encrypting Android backups with the user's screen lock secret (that is, PIN, pattern, or password). By design, this means that an attacker would not be able to access a user's backed-up application data without specifically knowing their passcode. Auto backup for apps has been enhanced by providing developers a way to specify conditions under which their app's data is excluded from auto backup. For example, Android Pie introduces a new flag to determine whether a user's backup is client-side encrypted.

As part of a larger effort to move all web traffic away from cleartext (unencrypted HTTP) and towards being secured with TLS (HTTPS), we changed the defaults for Network Security Configuration to block all cleartext traffic. We're protecting users with TLS by default, unless you explicitly opt-in to cleartext for specific domains. Android Pie also adds built-in support for DNS over TLS, automatically upgrading DNS queries to TLS if a network's DNS server supports it. This protects information about IP addresses visited from being sniffed or intercepted on the network level.


We believe that the features described in this post advance the security and privacy posture of Android, but you don't have to take our word for it. Year after year our continued efforts are demonstrably resulting in better protection as evidenced by increasing exploit difficulty and independent mobile security ratings. Now go and enjoy some actual pie while we get back to preparing the next Android dessert release!

Making Android more secure requires a combination of hardening the platform and advancing anti-exploitation techniques.


Acknowledgements: 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.
Kategorie: Hacking & Security