Google Online Security Blog: 2016

Project Wycheproof

December 19, 2016

Posted by Daniel Bleichenbacher, Security Engineer and Thai Duong, Security EngineerProject Wycheproof40 security bugsDSAECDHCJava Cryptography ArchitectureBouncy CastleOpenJDKsmallest mountain in the worldProject WycheproofCONTRIBUTINGour homepage on GitHub

Announcing OSS-Fuzz: Continuous Fuzzing for Open Source Software

December 1, 2016

Posted by Mike Aizatsky, Kostya Serebryany (Software Engineers, Dynamic Tools); Oliver Chang, Abhishek Arya (Security Engineers, Google Chrome); and Meredith Whittaker (Open Research Lead)[Cross-posted from the Google Testing Blog and the Google Open Source Blog]OSS-FuzzCore Infrastructure InitiativeRecentsecuritystoriesbuffer overflowuse-after-freefuzz testingAFLlibFuzzerfuzz various components of the Chrome browserSanitizerssometimesAddressSanitizerClusterFuzzEarly successes
FreeTypebillion deviceswasFreeType fuzzernew heap buffer overflowERROR: AddressSanitizer: heap-buffer-overflow on address 0x615000000ffa READ of size 2 at 0x615000000ffa thread T0 SCARINESS: 24 (2-byte-read-heap-buffer-overflow-far-from-bounds) #0 0x885e06 in tt_face_vary_cvtsrc/truetype/ttgxvar.c:1556:31 notifiedfixedconfirmedfull list
Contributions and feedback are welcome
150 bugsprojects~4 trillion test casesheretrackerherebest practicesGitHub

Pixel Security: Better, Faster, Stronger

November 17, 2016

Posted by Paul Crowley, Senior Software Engineer and Paul Lawrence, Senior Software Engineer[Cross-posted from the Android Developers Blog]security improvements

File-Based Encryption Direct Boot experiencefile-based encryptionDirect boot
Enhanced with TrustZone® security

TrustZone enforces the Verified Boot process. If TrustZone detects that the operating system has been modified, it won't decrypt disk encryption keys; this helps to secure device encrypted (DE) data.

TrustZone enforces a waiting period between guesses at the user credential, which gets longer after a sequence of wrong guesses. With 1624 valid four-point patterns and TrustZone's ever-growing waiting period, trying all patterns would take more than four years. This improves security for all users, especially those who have a shorter and more easily guessed pattern, PIN, or password.

Encryption on Pixel phones
Protecting different folders with different keys required a distinct approach from full-disk encryption (FDE). The natural choice for Linux-based systems is the industry-standard eCryptFS. However, eCryptFS didn't meet our performance requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked with the ext4 maintainer, Ted Ts'o, to add encryption natively to ext4, and Android became the first consumer of this technology. ext4 encryption performance is similar to full-disk encryption, which is as performant as a software-only solution can be.

Additionally, Pixel phones have an inline hardware encryption engine, which gives them the ability to write encrypted data at line speed to the flash memory. To take advantage of this, we modified ext4 encryption to use this hardware by adding a key reference to the bio structure, within the ext4 driver before passing it to the block layer. (The bio structure is the basic container for block I/O in the Linux kernel.) We then modified the inline encryption block driver to pass this to the hardware. As with ext4 encryption, keys are managed by the Linux keyring. To see our implementation, take a look at the source code for the Pixel kernel.

While this specific implementation of file-based encryption using ext4 with inline encryption benefits Pixel users, FBE is available in AOSP and ready to use, along with the other features mentioned in this post.

SHA-1 Certificates in Chrome

November 16, 2016

Posted by Andrew Whalley, Chrome Securityseveralannouncementsshowed signs of weaknessrecent researchRelease schedulearound the end of January 2017Chrome release processto checkSHA-1 use in private PKIsChrome 54EnableSha1ForLocalAnchorspolicyrequire a secure origin

A new site for Safe Browsing

November 9, 2016

Posted by Mike Castner and Brooke Heinichen, Safe Browsing Teamlaunching in 2007Chrome users on Androidseveralimprovementsa new site for Safe BrowsingTransparency ReportSearch ConsoleSafe Browsing AlertsSafe Browsing website

Protecting users from repeatedly dangerous sites

November 8, 2016

Posted by Brooke Heinichen, Safe Browsing TeamMalwareUnwanted SoftwarePhishing, and Social Engineering PoliciesSearch ConsoleRepeat Offenders

Here’s to more HTTPS on the web!

November 3, 2016

Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Teamnew section to the HTTPS Report Card in our Transparency Report

Percentage of pages loaded over HTTPS in Chrome

As the remainder of the web transitions to HTTPS, we’ll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP. As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we’ve posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.

We’ve seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented: “We were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS.” CNET, a large tech news site, had a similar experience: “We successfully completed our move of CNET.com to HTTPS last month,” said John Sherwood, Vice President of Engineering & Technology at CNET. “Since then, there has been no change in our Google rankings or Google organic search traffic.”

Webmasters that include ads on their sites also should carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense, or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, “saw no material impact to AdX revenue with the transition to SSL.”

As migrating to HTTPS becomes even easier, we’ll continue working towards a web that’s secure by default. Don’t hesitate to start planning your HTTPS migration today!

Distrusting WoSign and StartCom Certificates

October 31, 2016

Posted by Andrew Whalley, Chrome SecurityRoot Certificate PolicyAppleMozilla
BackgroundWoSign misissuanceActionCertificate Transparency in Chrome

Disclosing vulnerabilities to protect users

October 31, 2016

Posted by Neel Mehta and Billy Leonard, Threat Analysis Groupon October 26thpublished policy for actively exploited critical vulnerabilitiesWin32k lockdown

OnHub: Powerful protection for peace of mind

September 27, 2016

Posted by Chris Millikin, Public Defender (Security Engineering Manager)[Cross-posted from the Official OnHub Blog]

Three Security features that set OnHub apart
1. Defense in Depth

internet security expertsglibcstrictly enforce it in Android NougatCSRFseccomp2. Hardware Provenancebugsinhosted3. Cloud IntelligenceSecurity Improvements, AutomaticallyGoogle’s Vulnerability Reward Programhere

Reshaping web defenses with strict Content Security Policy

September 26, 2016

Posted by Artur Janc, Michele Spagnuolo, Lukas Weichselbaum, and David Ross, Information Security EngineersCross-site scriptingVulnerability Reward Programstrict contextual auto-escapingautomated scannerstargeted exploitsrecent Internet-wide studyTowards safer CSP policiesCSP Evaluator

Content-Security-Policy: script-src 'nonce-random123'
<script nonce='random123'>alert('This script will run')</script><script>alert('Will not run: missing nonce')</script><script nonce='bad123'>alert("Won't run: invalid nonce")</script>
strict-dynamic'supportedscript-src 'nonce-random123' 'strict-dynamic'; object-src 'none'
<script>backwards-compatibleplays wellAdopting strict CSPCloud ConsolePhotosHistoryCareers SearchMaps TimelineCultural Institutebest strategies for implementing CSPbenefits of CSPcode changesCSP Mitigator

Encouraging broader use of strict CSPPatch Reward Programprogram rulesCSP refactoring tips

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[Updated on 12/5/16 with instructions for developers]Developershere

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.

Security Blog