Posted by Daniel Bleichenbacher, Security Engineer and Thai Duong, Security Engineer
We’re excited to announce the release of Project Wycheproof, a set of security tests that check cryptographic software libraries for known weaknesses. We’ve developed over 80 test cases which have uncovered more than 40 security bugs (some tests or bugs are not open sourced today, as they are being fixed by vendors). For example, we found that we could recover the private key of widely-used DSA and ECDHC implementations. We also provide ready-to-use tools to check Java Cryptography Architecture providers such as Bouncy Castle and the default providers in OpenJDK.

The main motivation for the project is to have an achievable goal. That’s why we’ve named it after the Mount Wycheproof, the smallest mountain in the world. The smaller the mountain the easier it is to climb it!

In cryptography, subtle mistakes can have catastrophic consequences, and mistakes in open source cryptographic software libraries repeat too often and remain undiscovered for too long. Good implementation guidelines, however, are hard to come by: understanding how to implement cryptography securely requires digesting decades' worth of academic literature. We recognize that software engineers fix and prevent bugs with unit testing, and we found that many cryptographic issues can be resolved by the same means.

These observations have prompted us to develop Project Wycheproof, a collection of unit tests that detect known weaknesses or check for expected behaviors of some cryptographic algorithm. Our cryptographers have surveyed the literature and implemented most known attacks. As a result, Project Wycheproof provides tests for most cryptographic algorithms, including RSA, elliptic curve crypto, and authenticated encryption.

Our first set of tests are written in Java, because Java has a common cryptographic interface. This allowed us to test multiple providers with a single test suite. While this interface is somewhat low level, and should not be used directly, we still apply a "defense in depth" argument and expect that the implementations are as robust as possible. For example, we consider weak default values to be a significant security flaw. We are converting as many tests into sets of test vectors to simplify porting the tests to other languages.

While we are committed to develop as many tests as possible and external contributions are welcome — if you want to contribute, please read CONTRIBUTING before sending us pull requests — Project Wycheproof is by no means complete. Passing the tests does not imply that the library is secure, it just means that it is not vulnerable to the attacks that Project Wycheproof tries to detect. Cryptographers constantly discover new weaknesses in cryptographic protocols. Nevertheless, with Project Wycheproof developers and users now can check their libraries against a large number of known attacks without having to sift through hundreds of academic papers or become cryptographers themselves.

For more information about the tests and what you can do with them, please visit our homepage on GitHub.

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]

We are happy to announce OSS-Fuzz, a new Beta program developed over the past years with the Core Infrastructure Initiative community. This program will provide continuous fuzzing for select core open source software.

Open source software is the backbone of the many apps, sites, services, and networked things that make up “the internet.” It is important that the open source foundation be stable, secure, and reliable, as cracks and weaknesses impact all who build on it.

Recent security stories confirm that errors like buffer overflow and use-after-free can have serious, widespread consequences when they occur in critical open source software. These errors are not only serious, but notoriously difficult to find via routine code audits, even for experienced developers. That's where fuzz testing comes in. By generating random inputs to a given program, fuzzing triggers and helps uncover errors quickly and thoroughly.

In recent years, several efficient general purpose fuzzing engines have been implemented (e.g. AFL and libFuzzer), and we use them to fuzz various components of the Chrome browser. These fuzzers, when combined with Sanitizers, can help find security vulnerabilities (e.g. buffer overflows, use-after-free, bad casts, integer overflows, etc), stability bugs (e.g. null dereferences, memory leaks, out-of-memory, assertion failures, etc) and sometimes even logical bugs.

OSS-Fuzz’s goal is to make common software infrastructure more secure and stable by combining modern fuzzing techniques with scalable distributed execution. OSS-Fuzz combines various fuzzing engines (initially, libFuzzer) with Sanitizers (initially, AddressSanitizer) and provides a massive distributed execution environment powered by ClusterFuzz.
Early successes

Our initial trials with OSS-Fuzz have had good results. An example is the FreeType library, which is used on over a billion devices to display text (and which might even be rendering the characters you are reading now). It is important for FreeType to be stable and secure in an age when fonts are loaded over the Internet. Werner Lemberg, one of the FreeType developers, was an early adopter of OSS-Fuzz. Recently the FreeType fuzzer found a new heap buffer overflow only a few hours after the source change:

ERROR: 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

OSS-Fuzz automatically notified the maintainer, who fixed the bug; then OSS-Fuzz automatically confirmed the fix. All in one day! You can see the full list of fixed and disclosed bugs found by OSS-Fuzz so far.

Contributions and feedback are welcome

OSS-Fuzz has already found 150 bugs in several widely used open source projects (and churns ~4 trillion test cases a week). With your help, we can make fuzzing a standard part of open source development, and work with the broader community of developers and security testers to ensure that bugs in critical open source applications, libraries, and APIs are discovered and fixed. We believe that this approach to automated security testing will result in real improvements to the security and stability of open source software.

OSS-Fuzz is launching in Beta right now, and will be accepting suggestions for candidate open source projects. In order for a project to be accepted to OSS-Fuzz, it needs to have a large user base and/or be critical to Global IT infrastructure, a general heuristic that we are intentionally leaving open to interpretation at this early stage. See more details and instructions on how to apply here.

Once a project is signed up for OSS-Fuzz, it is automatically subject to the 90-day disclosure deadline for newly reported bugs in our tracker (see details here). This matches industry’s best practices and improves end-user security and stability by getting patches to users faster.

Help us ensure this program is truly serving the open source community and the internet which relies on this critical software, contribute and leave your feedback on GitHub.

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

Encryption protects your data if your phone falls into someone else's hands. The new Google Pixel and Pixel XL are encrypted by default to offer strong data protection, while maintaining a great user experience with high I/O performance and long battery life. In addition to encryption, the Pixel phones debuted running the Android Nougat release, which has even more security improvements.

This blog post covers the encryption implementation on Google Pixel devices and how it improves the user experience, performance, and security of the device.
File-Based Encryption Direct Boot experience
One of the security features introduced in Android Nougat was file-based encryption. File-based encryption (FBE) means different files are encrypted with different keys that can be unlocked independently. FBE also separates data into device encrypted (DE) data and credential encrypted (CE) data.

Direct boot uses file-based encryption to allow a seamless user experience when a device reboots by combining the unlock and decrypt screen. For users, this means that applications like alarm clocks, accessibility settings, and phone calls are available immediately after boot.

Enhanced with TrustZone® security

Modern processors provide a means to execute code in a mode that remains secure even if the kernel is compromised. On ARM®-based processors this mode is known as TrustZone. Starting in Android Nougat, all disk encryption keys are stored encrypted with keys held by TrustZone software.

This secures encrypted data in two ways:

• 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.

Posted by Andrew Whalley, Chrome Security
We’ve previously made several announcements about Google Chrome's deprecation plans for SHA-1 certificates. This post provides an update on the final removal of support.

The SHA-1 cryptographic hash algorithm first showed signs of weakness over eleven years ago and recent research points to the imminent possibility of attacks that could directly impact the integrity of the Web PKI. To protect users from such attacks, Chrome will stop trusting certificates that use the SHA-1 algorithm, and visiting a site using such a certificate will result in an interstitial warning.
Release schedule
We are planning to remove support for SHA-1 certificates in Chrome 56, which will be released to the stable channel around the end of January 2017. The removal will follow the Chrome release process, moving from Dev to Beta to Stable; there won't be a date-based change in behaviour.

Website operators are urged to check for the use of SHA-1 certificates and immediately contact their CA for a SHA-256 based replacement if any are found.
SHA-1 use in private PKIs
Previous posts made a distinction between certificates which chain to a public CA and those which chain to a locally installed trust anchor, such as those of a private PKI within an enterprise. We recognise there might be rare cases where an enterprise wishes to make their own risk management decision to continue using SHA-1 certificates.

Starting with Chrome 54 we provide the EnableSha1ForLocalAnchors policy that allows certificates which chain to a locally installed trust anchor to be used after support has otherwise been removed from Chrome. Features which require a secure origin, such as geolocation, will continue to work, however pages will be displayed as “neutral, lacking security”. Without this policy set, SHA-1 certificates that chain to locally installed roots will not be trusted starting with Chrome 57, which will be released to the stable channel in March 2017. Note that even without the policy set, SHA-1 client certificates will still be presented to websites requesting client authentication.

Since this policy is intended only to allow additional time to complete the migration away from SHA-1, it will eventually be removed in the first Chrome release after January 1st 2019.

As Chrome makes use of certificate validation libraries provided by the host OS when possible, this option will have no effect if the underlying cryptographic library disables support for SHA-1 certificates; at that point, they will be unconditionally blocked. We may also remove support before 2019 if there is a serious cryptographic break of SHA-1. Enterprises are encouraged to make every effort to stop using SHA-1 certificates as soon as possible and to consult with their security team before enabling the policy.

Posted by Mike Castner and Brooke Heinichen, Safe Browsing Team
Since launching in 2007, the Safe Browsing team has been dedicated to our mission of protecting users from phishing, malware, and unwanted software on the web. Our coverage currently extends to more than two billion internet-connected devices, including Chrome users on Android. As part of our commitment to keep our users both protected and informed, we’ve recently launched several improvements to the way we share information.

Today, we’re happy to announce a new site for Safe Browsing that makes it easier for users to quickly report malicious sites, access our developer documentation, and find our policies. Our new site also serves as a central hub for our tools, including the Transparency Report, Search Console, and Safe Browsing Alerts for Network Administrators.

The new Safe Browsing website will be a platform for consolidated policy and help content. We’re excited to make this new, single source of information available to users, developers, and webmasters.

Posted by Brooke Heinichen, Safe Browsing Team

Since 2005, Safe Browsing has been protecting users from harm on the Internet, and has evolved over the years to adapt to the changing nature of threats and user harm.

Today, sites in violation of Google’s Malware, Unwanted Software, Phishing, and Social Engineering Policies show warnings until Google verifies that the site is no longer harmful. The verification can be triggered automatically, or at the request of the webmaster via the Search Console.

However, over time, we’ve observed that a small number of websites will cease harming users for long enough to have the warnings removed, and will then revert to harmful activity.

As a result of this gap in user protection, we have adjusted our policies to reduce risks borne by end-users. Starting today, Safe Browsing will begin to classify these types of sites as “Repeat Offenders.” With regards to Safe Browsing-related policies, Repeat Offenders are websites that repeatedly switch between compliant and policy-violating behavior for the purpose of having a successful review and having warnings removed. Please note that websites that are hacked will not be classified as Repeat Offenders; only sites that purposefully post harmful content will be subject to the policy.

Once Safe Browsing has determined that a site is a Repeat Offender, the webmaster will be unable to request additional reviews via the Search Console for 30 days, and warnings will continue to show to users. When a site is established as a Repeat Offender, the webmaster will be notified via email to their registered Search Console email address.

We continuously update our policies and practices to address evolving threats. This is yet another change to help protect users from harm online.

Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team
Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we’ve worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future. It’s happening now, with secure browsing becoming standard for users of Chrome.

Today, we’re adding a new section to the HTTPS Report Card in our Transparency Report that includes data about how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory.

Posted by Andrew Whalley, Chrome Security
Certificate Authorities (CAs) play a key role in web security by issuing digital certificates to website operators. These certificates are trusted by browsers to authenticate secure connections to websites. CAs who issue certificates outside the policies required by browsers and industry bodies can put the security and privacy of every web user at risk.

Google has determined that two CAs, WoSign and StartCom, have not maintained the high standards expected of CAs and will no longer be trusted by Google Chrome, in accordance with our Root Certificate Policy. This view is similar to the recent announcements by the root certificate programs of both Apple and Mozilla. The rest of this post provides background to that decision and how we plan to minimize disruption while still protecting users.

Background

On August 17, 2016, Google was notified by GitHub's security team that WoSign had issued a certificate for one of GitHub's domains without their authorization. This prompted an investigation, conducted in public as a collaboration with Mozilla and the security community, which found a number of other cases of WoSign misissuance.

The investigation concluded that WoSign knowingly and intentionally misissued certificates in order to circumvent browser restrictions and CA requirements. Further, it determined that StartCom, another CA, had been purchased by WoSign, and had replaced infrastructure, staff, policies, and issuance systems with WoSign's. When presented with this evidence, WoSign and StartCom management actively attempted to mislead the browser community about the acquisition and the relationship of these two companies. For both CAs, we have concluded there is a pattern of issues and incidents that indicate an approach to security that is not in concordance with the responsibilities of a publicly trusted CA.
Action

Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted. Certificates issued before this date may continue to be trusted, for a time, if they comply with the Certificate Transparency in Chrome policy or are issued to a limited set of domains known to be customers of WoSign and StartCom.

Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance. As a result of these changes, customers of WoSign and StartCom may find their certificates no longer work in Chrome 56.

In subsequent Chrome releases, these exceptions will be reduced and ultimately removed, culminating in the full distrust of these CAs. This staged approach is solely to ensure sites have the opportunity to transition to other Certificate Authorities that are still trusted in Google Chrome, thus minimizing disruption to users of these sites. Sites that find themselves on this whitelist will be able to request early removal once they’ve transitioned to new certificates. Any attempt by WoSign or StartCom to circumvent these controls will result in immediate and complete removal of trust.

We remain committed to ensuring the safety and privacy of Google Chrome users. We appreciate the impact to users visiting sites with affected certificates and to the operators who run these sites, but the nature of these incidents, and the need to protect our users, prevent us from being able to take less disruptive steps.

Posted by Neel Mehta and Billy Leonard, Threat Analysis Group
On Friday, October 21st, we reported 0-day vulnerabilities — previously publicly-unknown vulnerabilities — to Adobe and Microsoft. Adobe updated Flash on October 26th to address CVE-2016-7855; this update is available via Adobe's updater and Chrome auto-update.

After 7 days, per our published policy for actively exploited critical vulnerabilities, we are today disclosing the existence of a remaining critical vulnerability in Windows for which no advisory or fix has yet been released. This vulnerability is particularly serious because we know it is being actively exploited.

The Windows vulnerability is a local privilege escalation in the Windows kernel that can be used as a security sandbox escape. It can be triggered via the win32k.sys system call NtSetWindowLongPtr() for the index GWLP_ID on a window handle with GWL_STYLE set to WS_CHILD. Chrome's sandbox blocks win32k.sys system calls using the Win32k lockdown mitigation on Windows 10, which prevents exploitation of this sandbox escape vulnerability.

We encourage users to verify that auto-updaters have already updated Flash — and to manually update if not — and to apply Windows patches from Microsoft when they become available for the Windows vulnerability.

Posted by Chris Millikin, Public Defender (Security Engineering Manager)
[Cross-posted from the Official OnHub Blog]
Since OnHub launched, we've highlighted a variety of features that enable users to do the things they love online without having to deal with the annoying router issues that we've all experienced at one time or another. These include: Fast, reliable Wi-Fi for more than 100 devices at a time, easy streaming and sharing, and wide-ranging coverage that helps eliminate dead zones.

We haven't, however, highlighted one of OnHub's most powerful features: Industry-leading security. Your router is the first line of defense for your online world. Because bad actors are aware of the critical position routers occupy in the network, routers are frequently the target of security attacks.
OnHub’s security features go beyond those of the typical router: OnHub is hardened against a variety of attacks, protecting your home network from many online threats. Three features in particular help ensure OnHub protects your data and devices from a variety of threats.

Three Security features that set OnHub apart

1. Defense in Depth
There are many elements that go into creating a robust defense in depth.

Auto updates: OnHub regularly downloads automatic updates without you having to do anything--a long-established practice on mobile devices and software like Chrome, but one that appliances haven’t caught up with yet. These updates provide regular maintenance fixes and address critical vulnerabilities. They’re like the seatbelts of online security— internet security experts recommend that users always accept updates.

However, when updates don’t happen automatically, many people don’t bother. OnHub communicates directly with Google, and makes sure all software is signed and verified. For instance, when a vulnerability was found in a software library (glibc) earlier this year, we were able to update OnHub’s entire fleet of devices within just a few days. In comparison, the vast majority of other routers require active user intervention to protect against such threats.

Verified Boot: Verified Boot protects you by preventing compromised OnHubs from booting. We use this technology in Chromebooks, strictly enforce it in Android Nougat, and we implemented it in OnHub from the very beginning. This makes OnHub extremely difficult to attack or compromise. For instance, the device runs software that has been cryptographically signed by Google.

Cloud administration: A traditional router is commonly attacked through its local administration web interface, where attackers have taken advantage of exploits like CSRF to remotely take control and change critical settings like DNS, so we eliminated that from the beginning. Instead OnHub is managed through the cloud, with strong authentication and authorization, using a simple phone app. A read-only API is available only on the internal network, to provide important data to the OnHub app during setup and when troubleshooting.

Process isolation: We also layer multiple techniques such as process isolation (uid/gid separation, namespaces, capability whitelists) and seccomp filtering to isolate network-facing services, which helps reduce potential attack scenarios in a given application by preventing an attacker from making lateral movements in the system.

2. Hardware Provenance
Modern hardware devices include many types of chips, drivers, and firmware. It’s important to know what each part is doing and where it came from. Our security team works to track the origins of all hardware, software, and firmware that goes into OnHub, including those from third-party sources. If a vulnerability is ever found, OnHub security works to fix the problem immediately.

The same goes for the open source components of OnHub. Before shipping, we do comprehensive code reviews of critical attack surfaces (i.e. network facing daemons), looking for security vulnerabilities. For example, we reviewed miniupnpd, hostapd, and dnsmasq. As a result of those reviews, Google reported security bugs to the open source project maintainers and offered patches. Here are three that we fixed: bugs in hosted.

3. Cloud Intelligence
We use anonymized metrics from our fleet of OnHubs to quickly detect and counter potential threats. For example, since we know that DNS is often a target of attacks, we monitor DNS settings on all OnHub routers for activity that could indicate a security compromise. This is “cloud intelligence” – a benefit that Google is uniquely able to deliver. By connecting OnHub to the Google cloud, we provide the same level of protection you expect across all your Google apps and devices. Because you manage your router through the cloud using your secure Google identity, you don’t have to remember yet another password for managing your OnHub, and you don’t have to be at home to control it.

Security Improvements, Automatically
OnHub also participates in Google’s Vulnerability Reward Program, which started in 2010 to honor all of the cutting-edge external contributions that help us keep our users safe. Through this program, if you can find a qualifying bug in OnHub’s security, rewards range from $100 to $20,000. Click here for an outline of the rewards for the most common classes of bugs.

When it comes to security, not all routers are created equal. OnHub protects you and your network with security that continues to adapt to threats. We’re always improving OnHub security, and automatically update without users having to take any actions. As cybersecurity evolves and new threats emerge, OnHub will be ready to meet the latest challenges for years to come.

Posted by Artur Janc, Michele Spagnuolo, Lukas Weichselbaum, and David Ross, Information Security Engineers

Cross-site scripting — the ability to inject undesired scripts into a trusted web application — has been one of the top web security vulnerabilities for over a decade. Just in the past 2 years Google has awarded researchers over $1.2 million for reporting XSS bugs in our applications via the Vulnerability Reward Program. Modern web technologies such as strict contextual auto-escaping help developers avoid mistakes which lead to XSS, and automated scanners can catch classes of vulnerabilities during the testing process. However, in complex applications bugs inevitably slip by, allowing attacks ranging from harmless pranks to malicious targeted exploits.

Content Security Policy (CSP) is a mechanism designed to step in precisely when such bugs happen; it provides developers the ability to restrict which scripts are allowed to execute so that even if attackers can inject HTML into a vulnerable page, they should not be able to load malicious scripts and other types of resources. CSP is a flexible tool allowing developers to set a wide range of policies; it is supported — though not always in its entirety — by all modern browsers.

However, the flexibility of CSP also leads to its biggest problem: it makes it easy to set policies which appear to work, but offer no real security benefit. In a recent Internet-wide study we analyzed over 1 billion domains and found that 95% of deployed CSP policies are ineffective as a protection against XSS. One of the underlying reasons is that out of the 15 domains most commonly whitelisted by developers for loading external scripts as many as 14 expose patterns which allow attackers to bypass CSP protections. We believe it's important to improve this, and help the web ecosystem make full use of the potential of CSP.

Towards safer CSP policies
To help developers craft policies which meaningfully protect their applications, today we’re releasing the CSP Evaluator, a tool to visualize the effect of setting a policy and detect subtle misconfigurations. CSP Evaluator is used by security engineers and developers at Google to make sure policies provide a meaningful security benefit and cannot be subverted by attackers.
Even with such a helpful tool, building a safe script whitelist for a complex application is often all but impossible due to the number of popular domains with resources that allow CSP to be bypassed. Here’s where the idea of a nonce-based CSP policy comes in. Instead of whitelisting all allowed script locations, it’s often simpler to modify the application to prove that a script is trusted by the developer by giving it a nonce -- an unpredictable, single-use token which has to match a value set in the policy:

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>

With 'strict-dynamic', a part of the upcoming CSP3 specification already supported by Chrome and Opera (and coming soon to Firefox), adopting such policies in complex, modern applications becomes much easier. Developers can now set a single, short policy such as:

script-src 'nonce-random123' 'strict-dynamic'; object-src 'none'

and make sure that all static <script> elements contain a matching nonce attribute — in many cases this is all that’s needed to enjoy added protection against XSS since ‘strict-dynamic’ will take care of loading any trusted scripts added at runtime. This approach allows setting policies which are backwards-compatible with all CSP-aware browsers, and plays well with applications which already use a traditional CSP policy; it also simplifies the process of adopting CSP and doesn’t require changing the policy as the application evolves.

Adopting strict CSP
In the past months we’ve deployed this approach in several large Google applications, including Cloud Console, Photos, History, Careers Search, Maps Timeline, Cultural Institute and are working on many more. We believe this approach can also help other developers so today we’re publishing documentation discussing the best strategies for implementing CSP, including an overview of the benefits of CSP, sample policies, and examples of common code changes.

Further, today we’re releasing CSP Mitigator, a Chrome extension that helps developers review an application for compatibility with nonce-based CSP. The extension can be enabled for any URL prefix and will collect data about any programming patterns that need to be refactored to support CSP. This includes identifying scripts which do not have the correct nonce attribute, detecting inline event handlers, javascript: URIs, and several other more subtle patterns which might need attention.
As with the CSP Evaluator, we use the extension with our applications to help speed up the process of adopting nonce-based CSP policies nonce-based policies across Google.

Encouraging broader use of strict CSP
Finally, today we’re including CSP adoption efforts in the scope of the Patch Reward Program; proactive work to help make popular open-source web frameworks compatible with nonce-based CSP can qualify for rewards (but please read the program rules and CSP refactoring tips first). We hope that increased attention to this area will also encourage researchers to find new, creative ways to circumvent CSP restrictions, and help us further improve the mechanism so that we can better protect Internet users from web threats.

To reach out to us, email more-csp@google.com.

Posted by Stephan Somogyi, Safe Browsing Team & William Luh, Android Security Team
During Google I/O in June, we told everyone that we were going to make a device-local Safe Browsing API available to all Android developers later in the year. That time has come!

Starting with Google Play Services version 9.4, all Android developers can use our privacy-preserving, and highly network as well as power-efficient on-device Safe Browsing infrastructure to protect all of their apps’ users. Even better, the API is simple and straightforward to use.

Since we introduced client-side Safe Browsing on Android, updated our documentation for Safe Browsing Protocol Version 4 (pver4), and also released our reference pver4 implementation in Go, we’ve been able to see how much protection this new technology provides to all our users. Since our initial launch we’ve shown hundreds of millions of warnings, actively warning many millions of mobile users about badness before they’re exposed to it.

We look forward to all Android developers extending this same protection to their users, too.

Posted by Emily Schechter, Chrome Security Team
[Updated on 12/5/16 with instructions for developers]
Developers: Read more about how to update your sites here.

To help users browse the web safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Beginning in January 2017 (Chrome 56), we’ll mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure.

Posted by Xiaowen Xin, Android Security Team
[Cross-posted from the Android Developers Blog]

Over the course of the summer, we previewed a variety of security enhancements in Android 7.0 Nougat: an increased focus on security with our vulnerability rewards program, a new Direct Boot mode, re-architected mediaserver and hardened media stack, apps that are protected from accidental regressions to cleartext traffic, an update to the way Android handles trusted certificate authorities, strict enforcement of verified boot with error correction, and updates to the Linux kernel to reduce the attack surface and increase memory protection. Phew!

Now that Nougat has begun to roll out, we wanted to recap these updates in a single overview and highlight a few new improvements.
Direct Boot and encryption

In previous versions of Android, users with encrypted devices would have to enter their PIN/pattern/password by default during the boot process to decrypt their storage area and finish booting. With Android 7.0 Nougat, we’ve updated the underlying encryption scheme and streamlined the boot process to speed up rebooting your phone. Now your phone’s main features, like the phone app and your alarm clock, are ready right away before you even type your PIN, so people can call you and your alarm clock can wake you up. We call this feature Direct Boot.

Under the hood, file-based encryption enables this improved user experience. With this new encryption scheme, the system storage area, as well as each user profile storage area, are all encrypted separately. Unlike with full-disk encryption, where all data was encrypted as a single unit, per-profile-based encryption enables the system to reboot normally into a functional state using just device keys. Essential apps can opt-in to run in a limited state after reboot, and when you enter your lock screen credential, these apps then get access your user data to provide full functionality.

File-based encryption better isolates and protects individual users and profiles on a device by encrypting data at a finer granularity. Each profile is encrypted using a unique key that can only be unlocked by your PIN or password, so that your data can only be decrypted by you.

• 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.

Posted by Kelly Hope Harrington, Safe Browsing Team
For more than nine years, Safe Browsing has helped webmasters via Search Console with information about how to fix security issues with their sites. This includes relevant Help Center articles, example URLs to assist in diagnosing the presence of harmful content, and a process for webmasters to request reviews of their site after security issues are addressed. Over time, Safe Browsing has expanded its protection to cover additional threats to user safety such as Deceptive Sites and Unwanted Software.

To help webmasters be even more successful in resolving issues, we’re happy to announce that we’ve updated the information available in Search Console in the Security Issues report.

The updated information provides more specific explanations of six different security issues detected by Safe Browsing, including malware, deceptive pages, harmful downloads, and uncommon downloads. These explanations give webmasters more context and detail about what Safe Browsing found. We also offer tailored recommendations for each type of issue, including sample URLs that webmasters can check to identify the source of the issue, as well as specific remediation actions webmasters can take to resolve the issue.

We on the Safe Browsing team definitely recommend registering your site in Search Console even if it is not currently experiencing a security issue. We send notifications through Search Console so webmasters can address any issues that appear as quickly as possible.

Our goal is to help webmasters provide a safe and secure browsing experience for their users. We welcome any questions or feedback about the new features on the Google Webmaster Help Forum, where Top Contributors and Google employees are available to help.

For more information about Safe Browsing’s ongoing work to shine light on the state of web security and encourage safer web security practices, check out our summary of trends and findings on the Safe Browsing Transparency Report. If you’re interested in the tools Google provides for webmasters and developers dealing with hacked sites, this video provides a great overview.

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