Google Online Security Blog

Even More Safe Browsing on Android!

September 15, 2016

Posted by Stephan Somogyi, Safe Browsing Team & William Luh, Android Security Teamtold everyoneGoogle Play Services version 9.4the API is simple and straightforward to usedocumentation for Safe Browsing Protocol Version 4reference pver4 implementation in Goour initial launch

Moving towards a more secure web

September 8, 2016

Posted by Emily Schechter, Chrome Security Team

Chrome currently indicates HTTP connections with a neutral indicator. This doesn’t reflect the true lack of security for HTTP connections. When you load a website over HTTP, someone else on the network can look at or modify the site before it gets to you.

A substantial portion of web traffic has transitioned to HTTPS so far, and HTTPS usage is consistently increasing. We recently hit a milestone with more than half of Chrome desktop page loads now served over HTTPS. In addition, since the time we released our HTTPS report in February, 12 more of the top 100 websites have changed their serving default from HTTP to HTTPS.

Studies show that users do not perceive the lack of a “secure” icon as a warning, but also that users become blind to warnings that occur too frequently. Our plan to label HTTP sites more clearly and accurately as non-secure will take place in gradual steps, based on increasingly stringent criteria. Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as "not secure," given their particularly sensitive nature.

In following releases, we will continue to extend HTTP warnings, for example, by labelling HTTP pages as “not secure” in Incognito mode, where users may have higher expectations of privacy. Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.

We will publish updates to this plan as we approach future releases, but don’t wait to get started moving to HTTPS. HTTPS is easier and cheaper than ever before, and enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our set-up guides to get started.

Keeping Android safe: Security enhancements in Nougat

September 6, 2016

Posted by Xiaowen Xin, Android Security Team[Cross-posted from the Android Developers Blog]vulnerability rewards programDirect Boot modehardened media stackaccidental regressions to cleartext traffictrusted certificate authoritiesverified bootupdates to the Linux kernel to reduce the attack surface and increase memory protectionDirect Boot and encryption
Direct Boot

Encryption support is getting stronger across the Android ecosystem as well. Starting with Marshmallow, all capable devices were required to support encryption. Many devices, like Nexus 5X and 6P also use unique keys that are accessible only with trusted hardware, such as the ARM TrustZone. Now with 7.0 Nougat, all new capable Android devices must also have this kind of hardware support for key storage and provide brute force protection while verifying your lock screen credential before these keys can be used. This way, all of your data can only be decrypted on that exact device and only by you.

The media stack and platform hardening
In Android Nougat, we’ve both hardened and re-architected mediaserver, one of the main system services that processes untrusted input. First, by incorporating integer overflow sanitization, part of Clang’s UndefinedBehaviorSanitizer, we prevent an entire class of vulnerabilities, which comprise the majority of reported libstagefright bugs. As soon as an integer overflow is detected, we shut down the process so an attack is stopped. Second, we’ve modularized the media stack to put different components into individual sandboxes and tightened the privileges of each sandbox to have the minimum privileges required to perform its job. With this containment technique, a compromise in many parts of the stack grants the attacker access to significantly fewer permissions and significantly reduced exposed kernel attack surface.
In addition to hardening the mediaserver, we’ve added a large list of protections for the platform, including:

Verified Boot: Verified Boot is now strictly enforced to prevent compromised devices from booting; it supports error correction to improve reliability against non-malicious data corruption.

SELinux: Updated SELinux configuration and increased Seccomp coverage further locks down the application sandbox and reduces attack surface. Library load order randomization and improved ASLR: Increased randomness makes some code-reuse attacks less reliable.

Kernel hardening: Added additional memory protection for newer kernels by marking portions of kernel memory as read-only, restricting kernel access to userspace addresses, and further reducing the existing attack surface.

APK signature scheme v2: Introduced a whole-file signature scheme that improves verification speed and strengthens integrity guarantees.

App security improvements
Android Nougat is the safest and easiest version of Android for application developers to use.

Apps that want to share data with other apps now must explicitly opt-in by offering their files through a Content Provider, like FileProvider. The application private directory (usually /data/data/) is now set to Linux permission 0700 for apps targeting API Level 24+.
To make it easier for apps to control access to their secure network traffic, user-installed certificate authorities and those installed through Device Admin APIs are no longer trusted by default for apps targeting API Level 24+. Additionally, all new Android devices must ship with the same trusted CA store.
With Network Security Config, developers can more easily configure network security policy through a declarative configuration file. This includes blocking cleartext traffic, configuring the set of trusted CAs and certificates, and setting up a separate debug configuration.

We’ve also continued to refine app permissions and capabilities to protect you from potentially harmful apps.

To improve device privacy, we have further restricted and removed access to persistent device identifiers such as MAC addresses.
User interface overlays can no longer be displayed on top of permissions dialogs. This “clickjacking” technique was used by some apps to attempt to gain permissions improperly.
We’ve reduced the power of device admin applications so they can no longer change your lockscreen if you have a lockscreen set, and device admin will no longer be notified of impending disable via onDisableRequested(). These were tactics used by some ransomware to gain control of a device.

System Updates

Lastly, we've made significant enhancements to the OTA update system to keep your device up-to-date much more easily with the latest system software and security patches. We've made the install time for OTAs faster, and the OTA size smaller for security updates. You no longer have to wait for the optimizing apps step, which was one of the slowest parts of the update process, because the new JIT compiler has been optimized to make installs and updates lightning fast.
The update experience is even faster for new Android devices running Nougat with updated firmware. Like they do with Chromebooks, updates are applied in the background while the device continues to run normally. These updates are applied to a different system partition, and when you reboot, it will seamlessly switch to that new partition running the new system software version.
We’re constantly working to improve Android security and Android Nougat brings significant security improvements across all fronts. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at security@android.com.

More Safe Browsing Help for Webmasters

September 6, 2016

Posted by Kelly Hope Harrington, Safe Browsing Teamnine yearsDeceptive SitesUnwanted Software

malwaredeceptive pagesharmful downloadsuncommon downloadsregisteringas quickly as possibleGoogle Webmaster Help ForumTop ContributorsSafe Browsing Transparency Reportvideo

Guided in-process fuzzing of Chrome components

August 5, 2016

Posted by Max Moroz, Chrome Security Engineer and Kostya Serebryany, Sanitizer TsarAddressSanitizerClusterFuzzSyzyASANThreadSanitizerotherslibFuzzerLLVMin-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.

LibFuzzer makes it possible to fuzz individual components of Chrome. This means you don’t need to generate an HTML page or network payload and launch the whole browser, which adds overhead and flakiness to testing. Instead, you can fuzz any function or internal API directly. Based on our experience, libFuzzer-based fuzzing is extremely efficient, more reliable, and usually thousands of times faster than traditional out-of-process fuzzing.
Our goal is to have fuzz testing for every component of Chrome where fuzzing is applicable, and we hope all Chromium developers and external security researchers will contribute to this effort.
How to write a fuzz target
With libFuzzer, you need to write only one function, which we call a target function or a fuzz target. It accepts a data buffer and length as input and then feeds it into the code we want to test. And... that’s it!
The fuzz targets are not specific to libFuzzer. Currently, we also run them with AFL, and we expect to use other fuzzing engines in the future.
Sample Fuzzer

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
std::string buf;
woff2::WOFF2StringOut out(&buf);
out.SetMaxSize(30 * 1024 * 1024);
woff2::ConvertWOFF2ToTTF(data, size, &out);
return 0;
}
See also the build rule.
Sample Bug

==9896==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62e000022836 at pc 0x000000499c51 bp 0x7fffa0dc1450 sp 0x7fffa0dc0c00

WRITE of size 41994 at 0x62e000022836 thread T0

SCARINESS: 45 (multi-byte-write-heap-buffer-overflow)

#0 0x499c50 in __asan_memcpy

#1 0x4e6b50 in Read third_party/woff2/src/buffer.h:86:7

#2 0x4e6b50 in ReconstructGlyf third_party/woff2/src/woff2_dec.cc:500

#3 0x4e6b50 in ReconstructFont third_party/woff2/src/woff2_dec.cc:917

#4 0x4e6b50 in woff2::ConvertWOFF2ToTTF(unsigned char const*, unsigned long, woff2::WOFF2Out*) third_party/woff2/src/woff2_dec.cc:1282

#5 0x4dbfd6 in LLVMFuzzerTestOneInput testing/libfuzzer/fuzzers/convert_woff2ttf_fuzzer.cc:15:3

Check out our documentation for additional information.

Integrating LibFuzzer with ClusterFuzzClusterFuzzexamplesEfficient Fuzzer Guide

AddressSanitizer (ASan): 500 GCE VMs

MemorySanitizer (MSan): 100 GCE VMs

UndefinedBehaviorSanitizer (UBSan): 100 GCE VMs

Sample Fuzzer Statistics

It’s important to track and analyze performance of fuzzers. So, we have this dashboard to track fuzzer statistics, that is accessible to all chromium developers:

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.

New research: Zeroing in on deceptive software installations

August 4, 2016

Posted by Kurt Thomas, Research Scientist and Juan A. Elices Crespo, Software Engineerprotect users from unwanted softwareunwanted ad injectorsbrowser settings hijackersNYU Tandon School of Engineeringread hereUSENIX Security SymposiumBehind the scenes of unwanted software distribution

Software bundle installation dialogue. Accepting the express install option will cause eight other programs to be installed with no indication of each program’s functionality.

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.

This decentralized model encourages advertisers to focus solely on monetizing users upon installation and for publishers to maximize conversion, irrespective of the final user experience. It takes only one bad actor anywhere in the distribution chain for unwanted installs to manifest.

What gets bundled?
We monitored the offers bundled by four of the largest pay-per-install affiliate networks on a daily basis for over a year. In total, we collected 446K offers related to 843 unique software packages. The most commonly bundled software included unwanted ad injectors, browser settings hijackers, and scareware purporting to fix urgent issues with a victim’s machine for $30-40. Here’s an example of an ad injector impersonating an anti-virus alert to scam users into fixing non-existent system issues:

Deceptive practices
Taken as a whole, we found 59% of weekly offers bundled by pay-per-install affiliate networks were flagged by at least one anti-virus engine as potentially unwanted. In response, software bundles will first fingerprint a user’s machine prior to installation to detect the presence of “hostile” anti-virus engines. Furthermore, in response to protections provide by Google Safe Browsing, publishers have resorted to increasingly convoluted tactics to try and avoid detection, like the defunct technique shown below of password protecting compressed binaries:

Paired with deceptive promotional tools like fake video codecs, software updates, or misrepresented brands, there are a multitude of deceptive behaviors currently pervasive to software bundling.

Cleaning up the ecosystem
We are constantly improving Google Safe Browsing defenses and the Chrome Cleanup Tool to protect users from unwanted software installs. When it comes to our ads policy, we take quick action to block and remove advertisers who misrepresent downloads or distribute software that violates Google’s unwanted software policy.
Additionally, Google is pushing for real change from businesses involved in the pay-per-install market to address the deceptive practices of some participants. As part of this, Google recently hosted a Clean Software Summit bringing together members of the anti-virus industry, bundling platforms, and the Clean Software Alliance. Together, we laid the groundwork for an industry-wide initiative to provide users with clear choices when installing software and to block deceptive actors pushing unwanted installs. We continue to advocate on behalf of users to ensure they remain safe while downloading software online.

Adding YouTube and Calendar to the HTTPS Transparency Report

August 1, 2016

Posted by Emily Schechter, HTTPS Enthusiastlaunched

Case study: YouTubeYouTube’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.

We're also proud to be using HTTP Secure Transport Security (HSTS) on youtube.com to cut down on HTTP to HTTPS redirects. This improves both security and latency for end users. Our HSTS lifetime is one year, and we hope to preload this soon in web browsers.
97% for YouTube is pretty good, but why isn't YouTube at 100%? In short, some devices do not fully support modern HTTPS. Over time, to keep YouTube users as safe as possible, we will gradually phase out insecure connections.

We know that any non-secure HTTP traffic could be vulnerable to attackers. All websites and apps should be protected with HTTPS — if you’re a developer that hasn’t yet migrated, get started today.

Bringing HSTS to www.google.com

July 29, 2016

Posted by Jay Brown, Sr. Technical Program Manager, Securityvast majority of these connectionsHSTSwww.google.com
Preparing for launchmixed contentDeployment and next stepswww.google.comwww.google.com

Protecting Android with more Linux kernel defenses

July 27, 2016

Posted by Jeff Vander Stoep, Android Security team[Cross-posted from the Android Developers Blog]Memory ProtectionsMark Memory As Read-Only/No-ExecuteGrsecurity’sarm64Restrict Kernel Access to User SpaceAndroid’s 4.1Improve Protection Against Stack Buffer Overflowsstack buffer overflowsmore array typesadded to the gcc 4.9 compiler
Attack Surface ReductionRemove Default Access to Debug Featureskernel patchBen Hutchingscontributed by Daniel MicayWish WuRestrict App Access to IOCTL CommandsIoctl command whitelisting with SELinuxCVE-2016-0820Require SECCOMP-BPFmedia hardening effort
Ongoing Efforts

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.

Due to these efforts and others, we expect the security of the kernel to continue improving. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at security@android.com.

Changes to Trusted Certificate Authorities in Android Nougat

July 8, 2016

Posted by Chad Brubaker, Android Security team[Cross-posted from the Android Developers Blog]

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.

Safe and easy APIsimproved the APIs User-added CAs Customizing trusted CAsthe full documentation Trusting custom CAs for debugging<network-security-config> <debug-overrides> <trust-anchors>  <certificates src="user" /> </trust-anchors> </domain-config> </network-security-config> Trusting custom CAs for a domain<network-security-config> <domain-config> <domain includeSubdomains="true">internal.example.com</domain> <trust-anchors>  <certificates src="@raw/cas" /> </trust-anchors> </domain-config> </network-security-config> Trusting user-added CAs for some domains<network-security-config> <domain-config> <domain includeSubdomains="true">userCaDomain.com</domain> <domain includeSubdomains="true">otherUserCaDomain.com</domain> <trust-anchors>  <certificates src="system" />  <certificates src="user" /> </trust-anchors> </domain-config> </network-security-config> Trusting user-added CAs for all domains except some<network-security-config> <base-config> <trust-anchors>  <certificates src="system" />  <certificates src="user" /> </trust-anchors> </base-config> <domain-config> <domain includeSubdomains="true">sensitive.example.com</domain> <trust-anchors>  <certificates src="system" /> <trust-anchors> </domain-config> </network-security-config> Trusting user-added CAs for all secure connections<network-security-config> <base-config> <trust-anchors>  <certificates src="system" />  <certificates src="user" /> </trust-anchors> </base-config> </network-security-config> Standardized set of system-trusted CAsAOSP What if I have a CA I believe should be included on Android?onlyCustomizing trusted CAsMozilla CA Inclusion Processfeature request

Security Blog

Even More Safe Browsing on Android!

Moving towards a more secure web

Keeping Android safe: Security enhancements in Nougat

More Safe Browsing Help for Webmasters

Guided in-process fuzzing of Chrome components

New research: Zeroing in on deceptive software installations

Adding YouTube and Calendar to the HTTPS Transparency Report

Bringing HSTS to www.google.com

Protecting Android with more Linux kernel defenses

Changes to Trusted Certificate Authorities in Android Nougat

Archive

Feed

Company-wide

Products

Developers