Google Data

Posted by Max Moroz, Chrome Security Engineer and Kostya Serebryany, Sanitizer Tsar

In the past, we’ve posted about innovations in fuzzing, a software testing technique used to discover coding errors and security vulnerabilities. The topics have included AddressSanitizer, ClusterFuzz, SyzyASAN, ThreadSanitizer and others.

Today we’d like to talk about libFuzzer (part of the LLVM project), an engine for in-process, coverage-guided, white-box fuzzing:

• By in-process, we mean that we don’t launch a new process for every test case, and that we mutate inputs directly in memory.
• By coverage-guided, we mean that we measure code coverage for every input, and accumulate test cases that increase overall coverage.
• By white-box, we mean that we use compile-time instrumentation of the source code.

Integrating LibFuzzer with ClusterFuzz

ClusterFuzz is Chromium’s infrastructure for large scale fuzzing. It automates crash detection, report deduplication, test minimization, and other tasks. Once you commit a fuzz target into the Chromium codebase (examples), ClusterFuzz will automatically pick it up and fuzz it with libFuzzer and AFL. 

ClusterFuzz supports most of the libFuzzer features like dictionaries, seed corpus and custom options for different fuzzers. Check out our Efficient Fuzzer Guide to learn how to use them.

Besides the initial seed corpus, we store, minimize, and synchronize the corpora for every fuzzer and across all bots. This allows us to continuously increase code coverage over time and find interesting bugs along the way.

ClusterFuzz uses the following memory debugging tools with libFuzzer-based fuzzers:

• AddressSanitizer (ASan): 500 GCE VMs
• MemorySanitizer (MSan): 100 GCE VMs
• UndefinedBehaviorSanitizer (UBSan): 100 GCE VMs

Overall statistics for the last 30 days:

• 120 fuzzers
• 112 bugs filed
• Aaaaaand…. 14,366,371,459,772 unique test inputs!

Analysis of the bugs found so far

Looking at the 324 bugs found so far, we can say that ASan and MSan have been very effective memory tools for finding security vulnerabilities. They give us comparable numbers of crashes, though ASan crashes usually are more severe than MSan ones. LSan (part of ASan) and UBSan have a great impact for Stability – another one of our 4 core principles.

Extending Chrome’s Vulnerability Reward Program

Under Chrome’s Trusted Researcher Program, we invite submission of fuzzers. We run them for you on ClusterFuzz and automatically nominate bugs they find for reward payments.

Today we’re pleased to announce that the invite-only Trusted Researcher Program is being replaced with the Chrome Fuzzer Program which encourages fuzzer submissions from all, and also covers libFuzzer-based fuzzers! Full guidelines are listed on Chrome’s Vulnerability Reward Program page.

Posted by Kurt Thomas, Research Scientist and Juan A. Elices Crespo, Software Engineer

As part of Google’s ongoing effort to protect users from unwanted software, we have been zeroing in on the deceptive installation tactics and actors that play a role in unwanted software delivery. This software includes unwanted ad injectors that insert unintended ads into webpages and browser settings hijackers that change search settings without user consent.

Every week, Google Safe Browsing generates over 60 million warnings to help users avoid installing unwanted software–that’s more than 3x the number of warnings we show for malware. Many of these warnings appear when users unwittingly download software bundles laden with several additional applications, a business model known as pay-per-install that earns up to $1.50 for each successful install. Recently, we finished the first in-depth investigation with NYU Tandon School of Engineering into multiple pay-per-install networks and the unwanted software families purchasing installs. The full report, which you can read here, will be presented next week at the USENIX Security Symposium.

Over a year-long period, we found four of the largest pay-per-install networks routinely distributed unwanted ad injectors, browser settings hijackers, and scareware flagged by over 30 anti-virus engines. These bundles were deceptively promoted through fake software updates, phony content lockers, and spoofed brands–techniques openly discussed on underground forums as ways to trick users into unintentionally downloading software and accepting the installation terms. While not all software bundles lead to unwanted software, critically, it takes only one deceptive party in a chain of web advertisements, pay-per-install networks, and application developers for abuse to manifest.
Behind the scenes of unwanted software distribution

If you have ever encountered an installation dialog like the one above, then you are already familiar with the pay-per-install distribution model. Behind the scenes there are a few different players:

• Advertisers: In pay-per-install lingo, advertisers are software developers, including unwanted software developers, paying for installs via bundling. In our example above, these advertisers include Plus-HD and Vuupc among others. The cost per install ranges anywhere from $0.10 in South America to $1.50 in the United States. Unwanted software developers will recoup this loss via ad injection, selling search traffic, or levying subscription fees. During our investigation, we identified 1,211 advertisers paying for installs.

• Affiliate networks: Affiliate networks serve as middlemen between advertisers looking to buy installs and popular software packages willing to bundle additional applications in return for a fee. These affiliate networks provide the core technology for tracking successful installs and billing. Additionally, they provide tools that attempt to thwart Google Safe Browsing or anti-virus detection. We spotted at least 50 affiliate networks fueling this business.

• Publishers: Finally, popular software applications re-package their binaries to include several advertiser offers. Publishers are then responsible for getting users to download and install their software through whatever means possible: download portals, organic page traffic, or often times deceptive ads. Our study uncovered 2,518 publishers distributing through 191,372 webpages.

Posted by Emily Schechter, HTTPS Enthusiast

Earlier this year, we launched a new section of our Transparency Report dedicated to HTTPS encryption. This report shows how much traffic is encrypted for Google products and popular sites across the web. Today, we’re adding two Google products to the report: YouTube and Calendar. The traffic for both products is currently more than 90% encrypted via HTTPS.

Case study: YouTube
As we’ve implemented HTTPS across products over the years, we’ve worked through a wide variety of technical obstacles. Below are some of the challenges we faced during YouTube’s two year road to HTTPS:

• Lots of traffic! Our CDN, the Google Global Cache, serves a massive amount of video, and migrating it all to HTTPS is no small feat. Luckily, hardware acceleration for AES is widespread, so we were able to encrypt virtually all video serving without adding machines. (Yes, HTTPS is fast now.)
• Lots of devices! You can watch YouTube videos on everything from flip phones to smart TVs. We A/B tested HTTPS on every device to ensure that users would not be negatively impacted. We found that HTTPS improved quality of experience on most clients: by ensuring content integrity, we virtually eliminated many types of streaming errors.
• Lots of requests! Mixed content—any insecure request made in a secure context—poses a challenge for any large website or app. We get an alert when an insecure request is made from any of our clients and eventually will block all mixed content using Content Security Policy on the web, App Transport Security on iOS, and uses CleartextTraffic on Android. Ads on YouTube have used HTTPS since 2014.

Posted by Jay Brown, Sr. Technical Program Manager, Security

For many years, we’ve worked to increase the use of encryption between our users and Google. Today, the vast majority of these connections are encrypted, and our work continues on this effort.

To further protect users, we’ve taken another step to strengthen how we use encryption for data in transit by implementing HTTP Strict Transport Security—HSTS for short—on the www.google.com domain. HSTS prevents people from accidentally navigating to HTTP URLs by automatically converting insecure HTTP URLs into secure HTTPS URLs. Users might navigate to these HTTP URLs by manually typing a protocol-less or HTTP URL in the address bar, or by following HTTP links from other websites.

Preparing for launch

Ordinarily, implementing HSTS is a relatively basic process. However, due to Google’s particular complexities, we needed to do some extra prep work that most other domains wouldn’t have needed to do. For example, we had to address mixed content, bad HREFs, redirects to HTTP, and other issues like updating legacy services which could cause problems for users as they try to access our core domain.

This process wasn’t without its pitfalls. Perhaps most memorably, we accidentally broke Google’s Santa Tracker just before Christmas last year (don’t worry — we fixed it before Santa and his reindeer made their trip).

Deployment and next steps

We’ve turned on HSTS for www.google.com, but some work remains on our deployment checklist.

In the immediate term, we’re focused on increasing the duration that the header is active (‘max-age’). We’ve initially set the header’s max-age to one day; the short duration helps mitigate the risk of any potential problems with this roll-out. By increasing the max-age, however, we reduce the likelihood that an initial request to www.google.com happens over HTTP. Over the next few months, we will ramp up the max-age of the header to at least one year.

Encrypting data in transit helps keep our users and their data secure. We’re excited to be implementing HSTS and will continue to extend it to more domains and Google products in the coming months.

Posted by Jeff Vander Stoep, Android Security team

[Cross-posted from the Android Developers Blog]

Android relies heavily on the Linux kernel for enforcement of its security model. To better protect the kernel, we’ve enabled a number of mechanisms within Android. At a high level these protections are grouped into two categories—memory protections and attack surface reduction.
Memory Protections
One of the major security features provided by the kernel is memory protection for userspace processes in the form of address space separation. Unlike userspace processes, the kernel’s various tasks live within one address space and a vulnerability anywhere in the kernel can potentially impact unrelated portions of the system’s memory. Kernel memory protections are designed to maintain the integrity of the kernel in spite of vulnerabilities.
Mark Memory As Read-Only/No-Execute
This feature segments kernel memory into logical sections and sets restrictive page access permissions on each section. Code is marked as read only + execute. Data sections are marked as no-execute and further segmented into read-only and read-write sections. This feature is enabled with config option CONFIG_DEBUG_RODATA. It was put together by Kees Cook and is based on a subset of Grsecurity’s KERNEXEC feature by Brad Spengler and Qualcomm’s CONFIG_STRICT_MEMORY_RWX feature by Larry Bassel and Laura Abbott. CONFIG_DEBUG_RODATA landed in the upstream kernel for arm/arm64 and has been backported to Android’s 3.18+ arm/arm64 common kernel.
Restrict Kernel Access to User Space
This feature improves protection of the kernel by preventing it from directly accessing userspace memory. This can make a number of attacks more difficult because attackers have significantly less control over kernel memory that is executable, particularly with CONFIG_DEBUG_RODATA enabled. Similar features were already in existence, the earliest being Grsecurity’s UDEREF. This feature is enabled with config option CONFIG_CPU_SW_DOMAIN_PAN and was implemented by Russell King for ARMv7 and backported to Android’s 4.1 kernel by Kees Cook.
Improve Protection Against Stack Buffer Overflows
Much like its predecessor, stack-protector, stack-protector-strong protects against stack buffer overflows, but additionally provides coverage for more array types, as the original only protected character arrays. Stack-protector-strong was implemented by Han Shan and added to the gcc 4.9 compiler.

Attack Surface Reduction
Attack surface reduction attempts to expose fewer entry points to the kernel without breaking legitimate functionality. Reducing attack surface can include removing code, removing access to entry points, or selectively exposing features.
Remove Default Access to Debug Features
The kernel’s perf system provides infrastructure for performance measurement and can be used for analyzing both the kernel and userspace applications. Perf is a valuable tool for developers, but adds unnecessary attack surface for the vast majority of Android users. In Android Nougat, access to perf will be blocked by default. Developers may still access perf by enabling developer settings and using adb to set a property: “adb shell setprop security.perf_harden 0”.
The patchset for blocking access to perf may be broken down into kernel and userspace sections. The kernel patch is by Ben Hutchings and is derived from Grsecurity’s CONFIG_GRKERNSEC_PERF_HARDEN by Brad Spengler. The userspace changes were contributed by Daniel Micay. Thanks to Wish Wu and others for responsibly disclosing security vulnerabilities in perf.
Restrict App Access to IOCTL Commands
Much of Android security model is described and enforced by SELinux. The ioctl() syscall represented a major gap in the granularity of enforcement via SELinux. Ioctl command whitelisting with SELinux was added as a means to provide per-command control over the ioctl syscall by SELinux.
Most of the kernel vulnerabilities reported on Android occur in drivers and are reached using the ioctl syscall, for example CVE-2016-0820. Some ioctl commands are needed by third-party applications, however most are not and access can be restricted without breaking legitimate functionality. In Android Nougat, only a small whitelist of socket ioctl commands are available to applications. For select devices, applications’ access to GPU ioctls has been similarly restricted.
Require SECCOMP-BPF
Seccomp provides an additional sandboxing mechanism allowing a process to restrict the syscalls and syscall arguments available using a configurable filter. Restricting the availability of syscalls can dramatically cut down on the exposed attack surface of the kernel. Since seccomp was first introduced on Nexus devices in Lollipop, its availability across the Android ecosystem has steadily improved. With Android Nougat, seccomp support is a requirement for all devices. On Android Nougat we are using seccomp on the mediaextractor and mediacodec processes as part of the media hardening effort.

Ongoing Efforts
There are other projects underway aimed at protecting the kernel:

• The Kernel Self Protection Project is developing runtime and compiler defenses for the upstream kernel.
• Further sandbox tightening and attack surface reduction with SELinux is ongoing in AOSP.
• Minijail provides a convenient mechanism for applying many containment and sandboxing features offered by the kernel, including seccomp filters and namespaces.
• Projects like kasan and kcov help fuzzers discover the root cause of crashes and to intelligently construct test cases that increase code coverage—ultimately resulting in a more efficient bug hunting process.

Posted by Chad Brubaker, Android Security team
[Cross-posted from the Android Developers Blog]
In Android Nougat, we’ve changed how Android handles trusted certificate authorities (CAs) to provide safer defaults for secure app traffic. Most apps and users should not be affected by these changes or need to take any action. The changes include:

• Safe and easy APIs to trust custom CAs.
• Apps that target API Level 24 and above no longer trust user or admin-added CAs for secure connections, by default.
• All devices running Android Nougat offer the same standardized set of system CAs—no device-specific customizations.

For more details on these changes and what to do if you’re affected by them, read on.

Safe and easy APIs

Apps have always been able customize which certificate authorities they trust. However, we saw apps making mistakes due to the complexities of the Java TLS APIs. To address this we improved the APIs for customizing trust.

User-added CAs

Protection of all application data is a key goal of the Android application sandbox. Android Nougat changes how applications interact with user- and admin-supplied CAs. By default, apps that target API level 24 will—by design—not honor such CAs unless the app explicitly opts in. This safe-by-default setting reduces application attack surface and encourages consistent handling of network and file-based application data.

Customizing trusted CAs

Customizing the CAs your app trusts on Android Nougat is easy using the Network Security Config. Trust can be specified across the whole app or only for connections to certain domains, as needed. Below are some examples for trusting a custom or user-added CA, in addition to the system CAs. For more examples and details, see the full documentation.

Trusting custom CAs for debugging

To allow your app to trust custom CAs only for local debugging, include something like this in your Network Security Config. The CAs will only be trusted while your app is marked as debuggable.

Trusting custom CAs for a domain

To allow your app to trust custom CAs for a specific domain, include something like this in your Network Security Config.

  
        
           internal.example.com  
             
                  
                  
             
        
 

Trusting user-added CAs for some domains

To allow your app to trust user-added CAs for multiple domains, include something like this in your Network Security Config.

  
        
           userCaDomain.com  
           otherUserCaDomain.com  
             
                    
                    
                    
                    
             
        
 

Trusting user-added CAs for all domains except some

To allow your app to trust user-added CAs for all domains, except for those specified, include something like this in your Network Security Config.

  
        
             
                  
                  
                  
                  
             
        
        
           sensitive.example.com  
             
                  
                  
             
        
 

Trusting user-added CAs for all secure connections

To allow your app to trust user-added CAs for all secure connections, add this in your Network Security Config.

Standardized set of system-trusted CAs

To provide a more consistent and more secure experience across the Android ecosystem, beginning with Android Nougat, compatible devices trust only the standardized system CAs maintained in AOSP.
Previously, the set of preinstalled CAs bundled with the system could vary from device to device. This could lead to compatibility issues when some devices did not include CAs that apps needed for connections as well as potential security issues if CAs that did not meet our security requirements were included on some devices.

What if I have a CA I believe should be included on Android?

First, be sure that your CA needs to be included in the system. The preinstalled CAs are only for CAs that meet our security requirements because they affect the secure connections of most apps on the device. If you need to add a CA for connecting to hosts that use that CA, you should instead customize your apps and services that connect to those hosts. For more information, see the Customizing trusted CAs section above.
If you operate a CA that you believe should be included in Android, first complete the Mozilla CA Inclusion Process and then file a feature requestagainst Android to have the CA added to the standardized set of system CAs.

Posted by Matt Braithwaite, Software Engineer
Quantum computers are a fundamentally different sort of computer that take advantage of aspects of quantum physics to solve certain sorts of problems dramatically faster than conventional computers can. While they will, no doubt, be of huge benefit in some areas of study, some of the problems that they are effective at solving are the ones that we use to secure digital communications. Specifically, if large quantum computers can be built then they may be able to break the asymmetric cryptographic primitives that are currently used in TLS, the security protocol behind HTTPS.

Quantum computers exist today but, for the moment, they are small and experimental, containing only a handful of quantum bits. It’s not even certain that large machines will ever be built, although Google, IBM, Microsoft, Intel and others are working on it. (Adiabatic quantum computers, like the D-Wave computer that Google operates with NASA, can have large numbers of quantum bits, but currently solve fundamentally different problems.)

However, a hypothetical, future quantum computer would be able to retrospectively decrypt any internet communication that was recorded today, and many types of information need to remain confidential for decades. Thus even the possibility of a future quantum computer is something that we should be thinking about today.
Experimenting with Post-quantum cryptography in Chrome
The study of cryptographic primitives that remain secure even against quantum computers is called “post-quantum cryptography”. Today we’re announcing an experiment in Chrome where a small fraction of connections between desktop Chrome and Google’s servers will use a post-quantum key-exchange algorithm in addition to the elliptic-curve key-exchange algorithm that would typically be used. By adding a post-quantum algorithm on top of the existing one, we are able to experiment without affecting user security. The post-quantum algorithm might turn out to be breakable even with today’s computers, in which case the elliptic-curve algorithm will still provide the best security that today’s technology can offer. Alternatively, if the post-quantum algorithm turns out to be secure then it’ll protect the connection even against a future, quantum computer.

Our aims with this experiment are to highlight an area of research that Google believes to be important and to gain real-world experience with the larger data structures that post-quantum algorithms will likely require.

We’re indebted to Erdem Alkim, Léo Ducas, Thomas Pöppelmann and Peter Schwabe, the researchers who developed “New Hope”, the post-quantum algorithm that we selected for this experiment. Their scheme looked to be the most promising post-quantum key-exchange when we investigated in December 2015. Their work builds upon earlier work by Bos, Costello, Naehrig and Stebila, and also on work by Lyubashevsky, Peikert and Regev.

We explicitly do not wish to make our selected post-quantum algorithm a de-facto standard. To this end we plan to discontinue this experiment within two years, hopefully by replacing it with something better. Since we selected New Hope, we’ve noted two promising papers in this space, which are welcome. Additionally, Google researchers, in collaboration with researchers from NXP, Microsoft, Centrum Wiskunde & Informatica and McMaster University, have just published another paper in this area. Practical research papers, such as these, are critical if cryptography is to have real-world impact.

This experiment is currently enabled in Chrome Canary and you can tell whether it’s being used by opening the recently introduced Security Panel and looking for “CECPQ1”, for example on https://play.google.com/store. Not all Google domains will have it enabled and the experiment may appear and disappear a few times if any issues are found.

While it’s still very early days for quantum computers, we’re excited to begin preparing for them, and to help ensure our users’ data will remain secure long into the future.

Posted by Quan To, Program Manager, Android Security

A year ago, we added Android Security Rewards to the long standing Google Vulnerability Rewards Program. We offered up to $38,000 per report that we used to fix vulnerabilities and protect Android users.

Since then, we have received over 250 qualifying vulnerability reports from researchers that have helped make Android and mobile security stronger. More than a third of them were reported in Media Server which has been hardened in Android N to make it more resistant to vulnerabilities.

While the program is focused on Nexus devices and has a primary goal of improving Android security, more than a quarter of the issues were reported in code that is developed and used outside of the Android Open Source Project. Fixing these kernel and device driver bugs helps improve security of the broader mobile industry (and even some non-mobile platforms).
By the Numbers
Here’s a quick rundown of the Android VRP’s first year:

• We paid over $550,000 to 82 individuals. That’s an average of $2,200 per reward and $6,700 per researcher.
• We paid our top researcher, @heisecode, $75,750 for 26 vulnerability reports.
• We paid 15 researchers $10,000 or more.
• There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise.

Posted by Emily Schechter and Alex Wozniak, Safe Browsing Team 

We’re excited to announce the launch of the new Safe Browsing API version 4. Version 4 replaces the existing Safe Browsing API version 3. With the launch of v4, we’re now starting the deprecation process for v2-3: please transition off of these older Safe Browsing protocol versions as soon as possible and onto protocol version 4.

Safe Browsing protects well over two billion internet-connected devices from threats like malware and phishing, and has done so for over a decade. We launched v1 of the Safe Browsing API in 2007 to give developers a simple mechanism to access Google’s lists of suspected unsafe sites.

The web has evolved since then and users are now increasingly using the web from their mobile devices. These devices have constraints less common to traditional desktop computing environments: mobile devices have very limited power and network bandwidth, and often poor quality of service. Additionally, cellular data costs our users money, so we have a responsibility to use it judiciously.

With protocol version 4, we’ve optimized for this new environment with a clear focus on maximizing protection per bit, which benefits all Safe Browsing users, mobile and desktop alike. Version 4 clients can now define constraints such as geographic location, platform type, and data caps to use bandwidth and device resources as efficiently as possible. This allows us to function well within the much stricter mobile constraints without sacrificing protection.

We’ve been using the new protocol since December via the Safe Browsing client on Android, which is part of Google Play Services. The first app to use the client is Chrome, starting with version 46: we’re already protecting hundreds of millions of Android Chrome users by default.

We’ve Done Most Of The Work For You Already

A single device should only have a single, up-to-date instance of Safe Browsing data, so we’re taking care of that for all Android developers. Please don’t implement your own Version 4 client on Android: we’re working on making a simple, device-local API available to prevent any resource waste on device. We’ll announce the availability of this new device-local API as soon as possible; in the meantime, there’s no need to develop a Version 4 client on your own. For those who operate in less resource-constrained environments, using the Safe Browsing Version 4 API directly allows you to:

• Check pages against the Safe Browsing lists based on platform and threat types.
• Warn users before they click links that may lead to infected pages.
• Prevent users from posting links to known infected pages

Posted by Dan Austin and Jeff Vander Stoep, Android Security team

[Cross-posted from the Android Developers Blog]

To help make Android more secure, we encourage and reward researchers who discover vulnerabilities. In 2015, a series of bugs in mediaserver’s libstagefright were disclosed to Google. We released updates for these issues with our August and September 2015 security bulletins.
In addition to addressing issues on a monthly basis, we’ve also been working on new security features designed to enhance the existing security model and provide additional defense in-depth. These defense measures attempt to achieve two goals:

• Prevention: Stop bugs from becoming vulnerabilities
• Containment: Protect the system by de-privileging and isolating components that handle untrusted content

Prevention

Most of the vulnerabilities found in libstagefright were heap overflows resulting from unsigned integer overflows. A number of integer overflows in libstagefright allowed an attacker to allocate a buffer with less space than necessary for the incoming data, resulting in a buffer overflow in the heap.
The result of an unsigned integer overflow is well defined, but the ensuing behavior could be unexpected or unsafe. In contrast, signed integer overflows are considered undefined behavior in C/C++, which means the result of an overflow is not guaranteed, and the compiler author may choose the resulting behavior—typically what is fastest or simplest. We have added compiler changes that are designed to provide safer defaults for both signed and unsigned integer overflows.
The UndefinedBehaviorSanitizer (UBSan) is part of the LLVM/Clang compiler toolchain that detects undefined or unintended behavior. UBSan can check for multiple types of undefined and unsafe behavior, including signed and unsigned integer overflow. These checks add code to the resulting executable, testing for integer overflow conditions during runtime. For example, figure 1 shows source code for the parseChunk function in the MPEG4Extractor component of libstagefright after the original researcher-supplied patch was applied. The modification, which is contained in the black box below, appears to prevent integer overflows from occurring. Unfortunately, while SIZE_MAX and size are 32-bit values, chunk_size is a 64-bit value, resulting in an incomplete check and the potential for integer overflow. In the line within the red box, the addition of size and chunk_size may result in an integer overflow and creation of buffer smaller than size elements. The subsequent memcpy could then lead to exploitable memory corruption, as size + chunk_size could be less than size, which is highlighted in the blue box. The mechanics of a potential exploit vector for this vulnerability are explained in more detail by Project Zero.

Figure 1. Source code demonstrating a subtle unsigned integer overflow.
Figure 2 compares assembly generated from the code segment above with a second version compiled with integer sanitization enabled. The add operation that results in the integer overflow is contained in the red box.
In the unsanitized version, size (r6) and chunk_size (r7) are added together, potentially resulting in r0 overflowing and being less than size. Then, buffer is allocated with the size specified in r0, and size bytes are copied to it. If r0 is less than r6, this results in memory corruption.
In the sanitized version, size (r7) and chunk_size (r5) are added together with the result stored in r0. Later, r0 is checked against r7, if r0 is less than r7, as indicated by the CC condition code, r3 is set to 1. If r3 is 1, and the carry bit was set, then an integer overflow occurred, and an abort is triggered, preventing memory corruption.
Note that the incomplete check provided in the patch was not included in figure 2. The overflow occurs in the buffer allocation’s add operation. This addition triggers an integer sanitization check, which turns this exploitable flaw into a harmless abort.

Figure 2. Comparing unsanitized and sanitized compiler output.
While the integer sanitizers were originally intended as code hygiene tools, they effectively prevent the majority of reported libstagefright vulnerabilities. Turning on the integer overflow checks was just the first step. Preventing the runtime abort by finding and fixing integer overflows, most of which are not exploitable, represented a large effort by Android’s media team. Most of the discovered overflows were fixed and those that remain (mostly for performance reasons) were verified and marked as safe to prevent the runtime abort.
In Android N, signed and unsigned integer overflow detection is enabled on the entire media stack, including libstagefright. This makes it harder to exploit integer overflows, and also helps to prevent future additions to Android from introducing new integer overflow bugs.

Containment

For Android M and earlier, the mediaserver process in Android was responsible for most media-related tasks. This meant that it required access to all permissions needed by those responsibilities and, although mediaserver ran in its own sandbox, it still had access to a lot of resources and capabilities. This is why the libstagefright bugs from 2015 were significant—mediaserver could access several important resources on an Android device including camera, microphone, graphics, phone, Bluetooth, and internet.
A root cause analysis showed that the libstagefright bugs primarily occurred in code responsible for parsing file formats and media codecs. This is not surprising—parsing complex file formats and codecs while trying to optimize for speed is hard, and the large number of edge cases makes such code susceptible to both accidental and malicious malformed inputs.
However, media parsers do not require access to most of the privileged permissions held by mediaserver. Because of this, the media team re-architected mediaserver in Android N to better adhere to the principle of least privilege. Figure 3 illustrates how the monolithic mediaserver and its permissions have been divided, using the following heuristics:

• parsing code moved into unprivileged sandboxes that have few or no permissions
• components that require sensitive permissions moved into separate sandboxes that only grant access to the specific resources the component needs. For example, only the cameraserver may access the camera, only the audioserver may access Bluetooth, and only the drmserver may access DRM resources.

Figure 3. How mediaserver and its permissions have been divided in Android N.
Comparing the potential impact of the libstagefright bugs on Android N and older versions demonstrates the value of this strategy. Gaining code execution in libstagefright previously granted access to all the permissions and resources available to the monolithic mediaserver process including graphics driver, camera driver, or sockets, which present a rich kernel attack surface.
In Android N, libstagefright runs within the mediacodec sandbox with access to very few permissions. Access to camera, microphone, photos, phone, Bluetooth, and internet as well as dynamic code loading are disallowed by SELinux. Interaction with the kernel is further restricted by seccomp. This means that compromising libstagefright would grant the attacker access to significantly fewer permissions and also mitigates privilege escalation by reducing the attack surface exposed by the kernel.

Conclusion

The media hardening project is an ongoing effort focused on moving functionality into less privileged sandboxes and further reducing the permissions granted to those sandboxes. While the techniques discussed here were applied to the Android media framework, they are suitable across the Android codebase. These hardening techniques—and others—are being actively applied to additional components within Android. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at .

Posted by Milinda Perera, Software Engineer, Security

HTTPS is fundamental to internet security; it protects the integrity and confidentiality of data sent between websites and visitors’ browsers. Last September, we began rolling out HTTPS support for blogspot domain blogs so you could try it out. Today, we’re launching another milestone: an HTTPS version for every blogspot domain blog. With this change, visitors can access any blogspot domain blog over an encrypted channel.

The HTTPS indicator in the Chrome browser

As part of this launch, we’re removing the HTTPS Availability setting. Even if you did not previously turn on this setting, your blogs will have an HTTPS version enabled.

We’re also adding a new setting called HTTPS Redirect that allows you to opt-in to redirect HTTP requests to HTTPS. While all blogspot blogs will have an HTTPS version enabled, if you turn on this new setting, all visitors will be redirected to the HTTPS version of your blog at https://.blogspot.com even if they go to http://.blogspot.com. If you choose to turn off this setting, visitors will have two options for viewing your blog: the unencrypted version at http://.blogspot.com or the encrypted version at https://.blogspot.com.

The new HTTPS Redirect setting in the Blogger dashboard

Please be aware that mixed content may cause some of your blog’s functionality not to work in the HTTPS version. Mixed content is often caused by incompatible templates, gadgets, or post content. While we’re proactively fixing most of these errors, some of them can only be fixed by you, the blog authors. To help spot and fix these errors, we recently released a mixed content warning tool that alerts you to possible mixed content issues in your posts, and gives you the option to fix them automatically before saving.

Existing links and bookmarks to your blogs are not affected by this launch, and will continue to work. Please note that blogs on custom domains will not yet have HTTPS support.

This update expands Google’s HTTPS Everywhere mission to all blogspot domain blogs. We appreciate your feedback and will use it to make future improvements.

Posted by Alex Klyubin, Android Security team

[Cross-posted from the Android Developers Blog]

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.
New Protections Mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next Steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at . HTTPS, Android-Security

Posted by Adrian Ludwig, Lead Engineer, Android Security
Today, for the second year in a row, we’re releasing our Android Security Annual report. This detailed summary includes: a look at how Google services protect the Android ecosystem, an overview of new security protections introduced in 2015, and our work with Android partners and the security research community at large. The full report is here, and an overview is below.

One important goal of releasing this report is to drive an informed conversation about Android security. We hope to accomplish this by providing more information about what we are doing, and what we see happening in the ecosystem. We strongly believe that rigorous, data-driven discussion about security will help guide our efforts to make the Android ecosystem safer.
Enhancing Google’s services to protect Android users

In the last year, we’ve significantly improved our machine learning and event correlation to detect potentially harmful behavior.

• We protected users from malware and other Potentially Harmful Apps (PHAs), checking over 6 billion installed applications per day.
• We protected users from network-based and on-device threats by scanning 400 million devices per day.
• And we protected hundreds of millions of Chrome users on Android from unsafe websites with Safe Browsing.

Posted by Kurt Thomas and Yuan Niu, Spam & Abuse Research
Every week, over 10 million users encounter harmful websites that deliver malware and scams. Many of these sites are compromised personal blogs or small business pages that have fallen victim due to a weak password or outdated software. Safe Browsing and Google Search protect visitors from dangerous content by displaying browser warnings and labeling search results with ‘this site may harm your computer’. While this helps keep users safe in the moment, the compromised site remains a problem that needs to be fixed.

Unfortunately, many webmasters for compromised sites are unaware anything is amiss. Worse yet, even when they learn of an incident, they may lack the security expertise to take action and address the root cause of compromise. Quoting one webmaster from a survey we conducted, “our daily and weekly backups were both infected” and even after seeking the help of a specialist, after “lots of wasted hours/days” the webmaster abandoned all attempts to restore the site and instead refocused his efforts on “rebuilding the site from scratch”.

In order to find the best way to help webmasters clean-up from compromise, we recently teamed up with the University of California, Berkeley to explore how to quickly contact webmasters and expedite recovery while minimizing the distress involved. We’ve summarized our key lessons below. The full study, which you can read here, was recently presented at the International World Wide Web Conference.

When Google works directly with webmasters during critical moments like security breaches, we can help 75% of webmasters re-secure their content. The whole process takes a median of 3 days. This is a better experience for webmasters and their audience.
How many sites get compromised?

Over the last year Google detected nearly 800,000 compromised websites—roughly 16,500 new sites every week from around the globe. Visitors to these sites are exposed to low-quality scam content and malware via drive-by downloads. While browser and search warnings help protect visitors from harm, these warnings can at times feel punitive to webmasters who learn only after-the-fact that their site was compromised. To balance the safety of our users with the experience of webmasters, we set out to find the best approach to help webmasters recover from security breaches and ultimately reconnect websites with their audience.
Finding the most effective ways to aid webmaster

1. Getting in touch with webmasters: One of the hardest steps on the road to recovery is first getting in contact with webmasters. We tried three notification channels: email, browser warnings, and search warnings. For webmasters who proactively registered their site with Search Console, we found that email communication led to 75% of webmasters re-securing their pages. When we didn’t know a webmaster’s email address, browser warnings and search warnings helped 54% and 43% of sites clean up respectively.
2. Providing tips on cleaning up harmful content: Attackers rely on hidden files, easy-to-miss redirects, and remote inclusions to serve scams and malware. This makes clean-up increasingly tricky. When we emailed webmasters, we included tips and samples of exactly which pages contained harmful content. This, combined with expedited notification, helped webmasters clean up 62% faster compared to no tips—usually within 3 days.
3. Making sure sites stay clean: Once a site is no longer serving harmful content, it’s important to make sure attackers don’t reassert control. We monitored recently cleaned websites and found 12% were compromised again in 30 days. This illustrates the challenge involved in identifying the root cause of a breach versus dealing with the side-effects.

Posted by Nirdhar Khazanie, Product Manager and Yossi Matias, VP Engineering

Last July, we launched Eddystone, an open and extensible Bluetooth Low Energy (BLE) beacon format from Google, supported by Android, iOS, and Chrome. Beacons mark important places and objects in a way that your phone can understand. To do this, they typically broadcast public one-way signals ‒ such as an Eddystone-UID or -URL.

Today, we’re introducing Ephemeral IDs (EID), a beacon frame in the Eddystone format that gives developers more power to control who can make use of the beacon signal. Eddystone-EID enables a new set of use cases where it is important for users to be able to exchange information securely and privately. Since the beacon frame changes periodically, the signal is only useful to clients with access to a resolution service that maps the beacon’s current identifier to stable data. In other words, the signal is only recognizable to a controlled set of users. In this post we’ll provide a bit more detail about this feature, as well as Google’s implementation of Eddystone-EID with Google Cloud Platform’s Proximity Beacon API and the Nearby API for Android and CocoaPod for iOS.

Technical Specifications

To an observer of an Eddystone-EID beacon, the AES-encrypted eight byte beacon identifier changes pseudo-randomly with an average period that is set by the developer ‒ over a range from 1 second to just over 9 hours. The identifier is generated using a key and timer running on the beacon. When the beacon is provisioned, or set up, the key is generated and exchanged with a resolution service such as Proximity Beacon API using an Elliptic Curve Diffie-Hellman key agreement protocol, and the timer is synchronized with the service. This way, only the beacon and the service that it is registered with have access to the key. You can read more about the technical details of Eddystone-EID from the specification ‒ including the provisioning process ‒ on GitHub, or from our recent preprint.

An Eddystone-EID contains measures designed to prevent a variety of nuanced attacks. For example, the rotation period for a single beacon varies slightly from identifier to identifier, meaning that an attacker cannot use a consistent period to identify a particular beacon. Eddystone-EID also enables safety features such as proximity awareness, device authentication, and data encryption on packet transmission. The Eddystone-TLM frame has also been extended with a new version that broadcasts battery level also encrypted with the shared key, meaning that an attacker cannot use the battery level as an identifying feature either.

When correctly implemented and combined with a service that supports a range of access control checks, such as Proximity Beacon API, this pattern has several advantages:

• The beacon’s location cannot be spoofed, except by a real-time relay of the beacon signal. This makes it ideal for use cases where a developer wishes to enable premium features for a user at a location.
• Beacons provide a high-quality and precise location signal that is valuable to the deployer. Eddystone-EID enables deployers to decide which developers/businesses can make use of that signal.
• Eddystone-EID beacons can be integrated into devices that users carry with them without leaving users vulnerable to tracking.