Google Security Blog

Syndikovat obsah
The latest news and insights from Google on security and safety on the Internet.
Aktualizace: 36 min 9 sek zpět

Expanding our Vulnerability Reward Program to combat platform abuse

15 Srpen, 2018 - 18:00
Posted by Eric Brown and Marc Henson, Trust & Safety

Since 2010, Google’s Vulnerability Reward Programs have awarded more than $12 million dollars to researchers and created a thriving Google-focused security community. For the past two years, some of these rewards were for bug reports that were not strictly security vulnerabilities, but techniques that allow third parties to successfully bypass our abuse, fraud, and spam systems.

Today, we are expanding our Vulnerability Reward Program to formally invite researchers to submit these reports.

This expansion is intended to reward research that helps us mitigate potential abuse methods. A few examples of potentially valid reports for this program could include bypassing our account recovery systems at scale, identifying services vulnerable to brute force attacks, circumventing restrictions on content use and sharing, or purchasing items from Google without paying. Valid reports tend to result in changes to the product’s code, as opposed to removal of individual pieces of content.

This program does not cover individual instances of abuse, such as the posting of content that violates our guidelines or policies, sending spam emails, or providing links to malware. These should continue to be reported through existing product-specific channels, such as for Google+, YouTube, Gmail, and Blogger.

Reports submitted to our Vulnerability Reward Program that outline abuse methods are reviewed by experts on our Trust & Safety team, which specializes in the prevention and mitigation of abuse, fraud, and spam activity on our products.

We greatly value our relationship with the research community, and we’re excited to expand on it to help make the internet a safer place for everyone. To learn more, see our updated rules.

Happy hunting!
Kategorie: Hacking & Security

Google Public DNS turns 8.8.8.8 years old

11 Srpen, 2018 - 03:31
Posted by Alexander Dupuy, Software Engineer

Once upon a time, we launched Google Public DNS, which you might know by its iconic IP address, 8.8.8.8. (Sunday, August 12th, 2018, at 00:30 UTC marks eight years, eight months, eight days and eight hours since the announcement.) Though not as well-known as Google Search or Gmail, the four eights have had quite a journey—and some pretty amazing growth! Whether it’s travelers in India’s train stations or researchers on the remote Antarctic island Bouvetøya, hundreds of millions of people the world over rely on our free DNS service to turn domain names like wikipedia.org into IP addresses like 208.80.154.224.
Google Public DNS query growth and major feature launches
Today, it’s estimated that about 10% of internet users rely on 8.8.8.8, and it serves well over a trillion queries per day. But while we’re really proud of that growth, what really matters is whether it’s a valuable service for our users. Namely, has Google Public DNS made the internet faster for users? Does it safeguard their privacy? And does it help them get to internet sites more reliably and securely?

In other words, has 8.8.8.8 made DNS and the internet better as a whole? Here at Google, we think it has. On this numerological anniversary, let’s take a look at how Google Public DNS has realized those goals and what lies ahead.
Making the internet faster

From the start, a key goal of Google Public DNS was to make the internet faster. When we began the project in 2007, Google had already made it faster to search the web, but it could take a while to get to your destination. Back then, most DNS lookups used your ISP’s resolvers, and with small caches, they often had to make multiple DNS queries before they could return an address.

Google Public DNS resolvers’ DNS caches hold tens of billions of entries worldwide. And because hundreds of millions of clients use them every day, they usually return the address for your domain queries without extra lookups, connecting you to the internet that much faster.
DNS resolution process for example.org
Speeding up DNS responses is just one part of making the web faster—getting web content from servers closer to you can have an even bigger impact. Content Delivery Networks (CDNs) distribute large, delay-sensitive content like streaming videos to users around the world. CDNs use DNS to direct users to the nearest servers, and rely on GeoIP maps to determine the best location.

Everything’s good if your DNS query comes from an ISP resolver that is close to you, but what happens if the resolver is far away, as it is for researchers on Bouvetøya? In that case, the CDN directs you to a server near the DNS resolver—but not the one closest to you. In 2010, along with other DNS and CDN services, we proposed a solution that lets DNS resolvers send part of your IP address in their DNS queries, so CDN name servers can get your best possible GeoIP location (short of sending your entire IP address). By sending only the first three parts of users’ IP addresses (e.g. 192.0.2.x) in the EDNS Client Subnet (ECS) extension, CDNs can return the closest content while maintaining user privacy.

We continue to enhance ECS, (now published as RFC 7871), for example, by adding automatic detection of name server ECS support. And today, we’re happy to report, support for ECS is widespread among CDNs.

Safeguarding user privacy

From day one of our service, we’ve always been serious about user privacy. Like all Google services, we honor the general Google Privacy Policy, and are guided by Google’s Privacy Principles. In addition, Google Public DNS published a privacy practice statement about the information we collect and how it is used—and how it’s not used. These protect the privacy of your DNS queries once they arrive at Google, but they can still be seen (and potentially modified) en route to 8.8.8.8.

To address this weakness, we launched a public beta of DNS-over-HTTPS on April 1, 2016, embedding your DNS queries in the secure and private HTTPS protocol. Despite the launch date, this was not an April Fool’s joke, and in the following two years, it has grown dramatically, with millions of users and support by another major public DNS service. Today, we are working in the IETF and with other DNS operators and clients on the Internet Draft for DNS Queries over HTTPS specification, which we also support.

Securing the Domain Name System

We’ve always been very concerned with the integrity and security of the responses that Google Public DNS provides. From the start, we rejected the practice of hijacking nonexistent domain (NXDOMAIN) responses, working to provide users with accurate and honest DNS responses, even when attackers tried to corrupt them.

In 2008, Dan Kaminsky publicized a major security weakness in the DNS protocol that left most DNS resolvers vulnerable to spoofing that poisoned their DNS caches. When we launched 8.8.8.8 the following year, we not only used industry best practices to mitigate this vulnerability, but also developed an extensive set of additional protections.

While those protected our DNS service from most attackers, they can’t help in cases where an attacker can see our queries. Starting in 2010, the internet started to use DNSSEC security in earnest, making it possible to protect cryptographically signed domains against such man-in-the-middle and man-on-the-side attacks. In 2013, Google Public DNS became the first major public DNS resolver to implement DNSSEC validation for all its DNS queries, doubling the percentage of end users protected by DNSSEC from 3.3% to 8.1%.

In addition to protecting the integrity of DNS responses, Google Public DNS also works to block DNS denial of service attacks by rate limiting both our queries to name servers and reflection or amplification attacks that try to flood victims’ network connections.

Internet access for all

A big part of Google Public DNS’s tremendous growth comes from free public internet services. We make the internet faster for hundreds of these services, from free WiFi in San Francisco’s parks to LinkNYC internet kiosk hotspots and the Railtel partnership in India‘s train stations. In places like Africa and Southeast Asia, many ISPs also use 8.8.8.8 to resolve their users’ DNS queries. Providing free DNS resolution to anyone in the world, even to other companies, supports internet access worldwide as a part of Google’s Next Billion Users initiative.

APNIC Labs map of worldwide usage (Interactive Map)
Looking ahead


Today, Google Public DNS is the largest public DNS resolver. There are now about a dozen such services providing value-added features like content and malware filtering, and recent entrants Quad9 and Cloudflare also provide privacy for DNS queries over TLS or HTTPS.

But recent incidents that used BGP hijacking to attack DNS are concerning. Increasing the adoption and use of DNSSEC is an effective way to protect against such attacks and as the largest DNSSEC validating resolver, we hope we can influence things in that direction. We are also exploring how to improve the security of the path from resolvers to authoritative name servers—issues not currently addressed by other DNS standards.

In short, we continue to improve Google Public DNS both behind the scenes and in ways visible to users, adding features that users want from their DNS service. Stay tuned for some exciting Google Public DNS announcements in the near future!
Kategorie: Hacking & Security

Mitigating Spectre with Site Isolation in Chrome

19 Červenec, 2018 - 16:44
Posted by Charlie Reis, Site Isolator

Speculative execution side-channel attacks like Spectre are a newly discovered security risk for web browsers. A website could use such attacks to steal data or login information from other websites that are open in the browser. To better mitigate these attacks, we're excited to announce that Chrome 67 has enabled a security feature called Site Isolation on Windows, Mac, Linux, and Chrome OS. Site Isolation has been optionally available as an experimental enterprise policy since Chrome 63, but many known issues have been resolved since then, making it practical to enable by default for all desktop Chrome users.

This launch is one phase of our overall Site Isolation project. Stay tuned for additional security updates that will mitigate attacks beyond Spectre (e.g., attacks from fully compromised renderer processes).

What is Spectre?

In January, Google Project Zero disclosed a set of speculative execution side-channel attacks that became publicly known as Spectre and Meltdown. An additional variant of Spectre was disclosed in May. These attacks use the speculative execution features of most CPUs to access parts of memory that should be off-limits to a piece of code, and then use timing attacks to discover the values stored in that memory. Effectively, this means that untrustworthy code may be able to read any memory in its process's address space.

This is particularly relevant for web browsers, since browsers run potentially malicious JavaScript code from multiple websites, often in the same process. In theory, a website could use such an attack to steal information from other websites, violating the Same Origin Policy. All major browsers have already deployed some mitigations for Spectre, including reducing timer granularity and changing their JavaScript compilers to make the attacks less likely to succeed. However, we believe the most effective mitigation is offered by approaches like Site Isolation, which try to avoid having data worth stealing in the same process, even if a Spectre attack occurs.

What is Site Isolation?

Site Isolation is a large change to Chrome's architecture that limits each renderer process to documents from a single site. As a result, Chrome can rely on the operating system to prevent attacks between processes, and thus, between sites. Note that Chrome uses a specific definition of "site" that includes just the scheme and registered domain. Thus, https://google.co.uk would be a site, and subdomains like https://maps.google.co.uk would stay in the same process.

Chrome has always had a multi-process architecture where different tabs could use different renderer processes. A given tab could even switch processes when navigating to a new site in some cases. However, it was still possible for an attacker's page to share a process with a victim's page. For example, cross-site iframes and cross-site pop-ups typically stayed in the same process as the page that created them. This would allow a successful Spectre attack to read data (e.g., cookies, passwords, etc.) belonging to other frames or pop-ups in its process.

When Site Isolation is enabled, each renderer process contains documents from at most one site. This means all navigations to cross-site documents cause a tab to switch processes. It also means all cross-site iframes are put into a different process than their parent frame, using "out-of-process iframes." Splitting a single page across multiple processes is a major change to how Chrome works, and the Chrome Security team has been pursuing this for several years, independently of Spectre. The first uses of out-of-process iframes shipped last year to improve the Chrome extension security model.
A single page may now be split across multiple renderer processes using out-of-process iframes.
Even when each renderer process is limited to documents from a single site, there is still a risk that an attacker's page could access and leak information from cross-site URLs by requesting them as subresources, such as images or scripts. Web browsers generally allow pages to embed images and scripts from any site. However, a page could try to request an HTML or JSON URL with sensitive data as if it were an image or script. This would normally fail to render and not expose the data to the page, but that data would still end up inside the renderer process where a Spectre attack might access it. To mitigate this, Site Isolation includes a feature called Cross-Origin Read Blocking (CORB), which is now part of the Fetch spec. CORB tries to transparently block cross-site HTML, XML, and JSON responses from the renderer process, with almost no impact to compatibility. To get the most protection from Site Isolation and CORB, web developers should check that their resources are served with the right MIME type and with the nosniff response header.

Site Isolation is a significant change to Chrome's behavior under the hood, but it generally shouldn't cause visible changes for most users or web developers (beyond a few known issues). It simply offers more protection between websites behind the scenes. Site Isolation does cause Chrome to create more renderer processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 10-13% total memory overhead in real workloads due to the larger number of processes. Our team continues to work hard to optimize this behavior to keep Chrome both fast and secure.

How does Site Isolation help?

In Chrome 67, Site Isolation has been enabled for 99% of users on Windows, Mac, Linux, and Chrome OS. (Given the large scope of this change, we are keeping a 1% holdback for now to monitor and improve performance.) This means that even if a Spectre attack were to occur in a malicious web page, data from other websites would generally not be loaded into the same process, and so there would be much less data available to the attacker. This significantly reduces the threat posed by Spectre.

Because of this, we are planning to re-enable precise timers and features like SharedArrayBuffer (which can be used as a precise timer) for desktop.

What additional work is in progress?

We're now investigating how to extend Site Isolation coverage to Chrome for Android, where there are additional known issues. Experimental enterprise policies for enabling Site Isolation will be available in Chrome 68 for Android, and it can be enabled manually on Android using chrome://flags/#enable-site-per-process.

We're also working on additional security checks in the browser process, which will let Site Isolation mitigate not just Spectre attacks but also attacks from fully compromised renderer processes. These additional enforcements will let us reach the original motivating goals for Site Isolation, where Chrome can effectively treat the entire renderer process as untrusted. Stay tuned for an update about these enforcements! Finally, other major browser vendors are finding related ways to defend against Spectre by better isolating sites. We are collaborating with them and are happy to see the progress across the web ecosystem.

Help improve Site Isolation!

We offer cash rewards to researchers who submit security bugs through the Chrome Vulnerability Reward Program. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards levels, up to twice the usual amount for information disclosure bugs. Find out more about Chrome New Feature Special Rewards.
Kategorie: Hacking & Security