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

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

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

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

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

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

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

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

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

User-added CAs

Customizing trusted CAs

Trusting custom CAs for debugging

<network-security-config>  
      <debug-overrides>  
           <trust-anchors>  
                <!-- Trust user added CAs while debuggable only -->
                <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>  
                <!-- Only trust the CAs included with the app  
                     for connections to internal.example.com -->  
                <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>  
                  <!-- Trust preinstalled CAs -->  
                  <certificates src="system" />  
                  <!-- Additionally trust user added CAs -->  
                  <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>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
      <domain-config>  
           <domain includeSubdomains="true">sensitive.example.com</domain>  
           <trust-anchors>  
                <!-- Only allow sensitive content to be exchanged  
             with the real server and not any user or  
    admin configured MiTMs -->  
                <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>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
 </network-security-config>

Standardized set of system-trusted CAs

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

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

• 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

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

Prevention

Containment

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

Conclusion

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

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.

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

• 22k ASNs are being monitored, or roughly 40% of active networks
• 1300 network administrators are actively using the tool
• 250 reports are sent daily to these administrators

1. Those that were once trusted and have since been withdrawn from the root programs.
2. New CAs that are on the path to inclusion in browser trusted roots.

• Compare binary files for x86, MIPS, ARM/AArch64, PowerPC, and other architectures.
• Identify identical and similar functions in different binaries.
• Port function names, comments and local variable names from one disassembly to another.
• Detect and highlight changes between two variants of the same function.

This chart represents the percentage of requests to Google's servers that used encrypted connections. YouTube traffic is currently not included in this data.

• Older hardware and/or software that doesn’t support modern encryption technologies.
• Governments and organizations that may block or otherwise degrade HTTPS traffic.
• Organizations that may not have the desire or technical resources to implement HTTPS.

• Increasing our top reward from $50,000 to $100,000. Last year we introduced a $50,000 reward for the persistent compromise of a Chromebook in guest mode. Since we introduced the $50,000 reward, we haven’t had a successful submission. That said, great research deserves great awards, so we’re putting up a standing six-figure sum, available all year round with no quotas and no maximum reward pool.

• Adding a Download Protection Bypass bounty. We’re extending our reward program scope to include rewards for methods that bypass Chrome’s Safe Browsing download protection features. There’s much more detail on this new category on our rewards page - be sure to take a look if you’re interested.

• Web Application Security Questionnaire
• Security & Privacy Program Questionnaire
• Infrastructure Security Questionnaire
• Physical & Data Center Security Questionnaire

Excerpt from Security and Privacy Programs Questionnaire

• Crash on free(ptr) where ptr is controlled by the attacker. 
• Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address. 
• Crash reading from memory pointed by a local overwritten variable. 
• Crash writing to memory on an attacker-controlled pointer.

• Pretend to act, or look and feel, like a trusted entity — like your own device or browser, or the website itself. 
• Try to trick you into doing something you’d only do for a trusted entity — like sharing a password or calling tech support.

• Tomasz Bojarski found 70 bugs on Google in 2015, and was our most prolific researcher of the year. He found a bug in our vulnerability submission form.
• You may have read about Sanmay Ved, a researcher from who was able to buy google.com for one minute on Google Domains. Our initial financial reward to Sanmay—$ 6,006.13—spelled-out Google, numerically (squint a little and you’ll see it!). We then doubled this amount when Sanmay donated his reward to charity.

• Adrienne Porter Felt will talk about blending research and engineering to solve usable security problems. You’ll hear how Chrome’s usable security team runs user studies and experiments to motivate engineering and design decisions. Adrienne will share the challenges they’ve faced when trying to adapt existing usable security research to practice, and give insight into how they’ve achieved successes.

• Ben Hawkes will be speaking about Project Zero, a security research team dedicated to the mission of, “making 0day hard.” Ben will talk about why Project Zero exists, and some of the recent trends and technologies that make vulnerability discovery and exploitation fundamentally harder.

• Kostya Serebryany will be presenting a 3-pronged approach to securing C++ code based on his many years of experiencing wrangling complex, buggy software. Kostya will survey multiple dynamic sanitizing tools him and his team have made publicly available, review control-flow and data-flow guided fuzzing, and explain a method to harden your code in the presence of any bugs that remain.

• Elie Bursztein will go through key lessons the Gmail team learned over the past 11 years while protecting users from spam, phishing, malware, and web attacks. Illustrated with concrete numbers and examples from one of the largest email systems on the planet, attendees will gain insight into specific techniques and approaches useful in fighting abuse and securing their online services.

1. is signed with a SHA-1-based signature
2. is issued on or after January 1, 2016
3. chains to a public CA

• It doesn’t contain insecure dependencies.
• It isn’t blocked from crawling by robots.txt.
• It doesn’t redirect users to or through an insecure HTTP page.
• It doesn’t have a rel="canonical" link to the HTTP page.
• It doesn’t contain a noindex robots meta tag.
• It doesn’t have on-host outlinks to HTTP URLs.
• The sitemaps lists the HTTPS URL, or doesn’t list the HTTP version of the URL.
• The server has a valid TLS certificate.

• It is deceptive, promising a value proposition that it does not meet.
• It tries to trick users into installing it or it piggybacks on the installation of another program.
• It doesn’t tell the user about all of its principal and significant functions.
• It affects the user’s system in unexpected ways.
• It is difficult to remove.
• It collects or transmits private information without the user’s knowledge.
• It is bundled with other software and its presence is not disclosed.

• We now include UwS in Safe Browsing and its API, enabling people who use Chrome and other browsers to see warnings before they go to sites that contain UwS. The red warning below appears in Chrome.

• We launched the Chrome Cleanup Tool, a one-shot UwS removal tool that has helped clean more than 40 million devices. We shed more light on a common symptom of UwS—unwanted ad injectors. We outlined how they make money and launched a new filter in DoubleClick Bid Manager that removes impressions generated by unwanted ad injectors before bids are made.
• We started using UwS as a signal in search to reduce the likelihood that sites with UwS would appear in search results.
• We started disabling Google ads that lead to sites with UwS downloads.

It’s still early, but these changes have already begun to move the needle.

• UwS-related Chrome user complaints have fallen. Last year, before we rolled-out our new policies, these were 40% of total complaints and now they’re 20%.
• We’re now showing more than 5 million Safe Browsing warnings per day on Chrome related to UwS to ensure users are aware of a site’s potential risks.
• We helped more than 14 million users remove over 190 deceptive Chrome extensions from their devices.
• We reduced the number of UwS warnings that users see via AdWords by 95%, compared to last year. Even prior to last year, less than 1% of UwS downloads were due to AdWords.

However, there is still a long way to go. 20% of all feedback from Chrome users is related to UwS and we believe 1 in 10 Chrome users have hijacked settings or unwanted ad injectors on their machines. We expect users of other browsers continue to suffer from similar issues; there is lots of work still to be done.

• Mobile data costs money for most users around the world. Data size matters a lot.
• Mobile data speeds are slower than Wi-Fi in much of the world. Data size matters a lot.
• Cellular connectivity quality is much more uneven, so getting the right data to the device quickly is critically important. Data size matters a lot.

• The content pretends to act, or looks and feels, like a trusted entity — like a bank or government.
• The content tries to trick you into doing something you’d only do for a trusted entity — like sharing a password or calling tech support.

1. A post-mortem analysis that details why they did not detect the additional certificates that we found.
2. Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.

1. This change is a better visual indication of the security state of the page relative to HTTP.
2. Chrome users will have fewer security states to learn.

1. TLS 1.2 must be supported.
2. A Server Name Indication (SNI) extension must be included in the handshake and must contain the domain that's being connected to.
3. The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be supported with P-256 and uncompressed points.
4. At least the certificates in https://pki.google.com/roots.pem must be trusted.
5. Certificate handling must be able to support DNS Subject Alternative Names and those SANs may include a single wildcard as the left-most label in the name.