Google Online Security Blog

News from the land of patch rewards

October 9, 2014

launchedPatch Reward
We started with a modest scope and reward amounts, but have gradually expanded the program over the past few months. We’ve seen some great work so far—and to help guide future submissions, we wanted to share some of our favorites:

Incorporation of a variety of web security checks directly into Django to help users develop safer web applications.

A support for seccomp-bpf sandboxing in BIND to minimize the impact of remote code execution bugs.

Addition of Curve25519 and several other primitives in OpenSSH to strengthen its cryptographic foundations and improve performance.

A set of patches to reduce the likelihood of ASLR info leaks in Linux to make certain types of memory corruption bugs more difficult to exploit.

And, of course, the recent attack-surface-reducing function prefix patch in bash that helped mitigate a flurry of “Shellshock”-related bugs.

We hope that this list inspires even more contributions in the year to come. Of course, before participating, be sure to read the rules page. When done, simply send your nominations to security-patches@google.com. And keep up the great work!
Posted by Michal Zalewski, Google Security Team

An update to SafeSearch options for network administrators

October 2, 2014

strong SSL encryption
For some time, we’ve offered network administrators the ability to require the use of SafeSearch by their users, which filters out explicit content from search results; this is especially important for schools. However, using this functionality has meant that searches were sent over an unencrypted connection to Google. Unfortunately, this has been the target of abuse by other groups looking to snoop on people’s searches, so we will be removing it as of early December.
Going forward, organizations can require SafeSearch on their networks while at the same time ensuring that their users’ connections to Google remain encrypted. (This is in addition to existing functionality that allows SafeSearch to be set on individual browsers and to be enabled by policy on managed devices like Chromebooks.) Network administrators can read more about how to enable this new feature here.
Posted by Brian Fitzpatrick, Engineering Director

Fewer bugs, mo’ money

September 30, 2014

Cross-posted on the Chromium Blog
bug reward programsecure
This is a good problem to have! In recognition of the extra effort it takes to uncover vulnerabilities in Chrome, we’re increasing our reward levels. We’re also making some changes to be more transparent with researchers reporting a bug.

First, we’re increasing our usual reward pricing range to $500-$15,000 per bug, up from a previous published maximum of $5,000. This is accompanied with a clear breakdown of likely reward amounts by bug type. As always, we reserve the right to reward above these levels for particularly great reports. (For example, last month we awarded $30,000 for a very impressive report.)

Second, we’ll pay at the higher end of the range when researchers can provide an exploit to demonstrate a specific attack path against our users. Researchers now have an option to submit the vulnerability first and follow up with an exploit later. We believe that this a win-win situation for security and researchers: we get to patch bugs earlier and our contributors get to lay claim to the bugs sooner, lowering the chances of submitting a duplicate report.

Third, Chrome reward recipients will be listed in the Google Hall of Fame, so you’ve got something to print out and hang on the fridge.

As a special treat, we’re going to back-pay valid submissions from July 1, 2014 at the increased reward levels we’re announcing today. Good times.

We’ve also answered some new FAQs on our rules page, including questions about our new Trusted Researcher program and a bit about our philosophy and alternative markets for zero-day bugs.

Happy bug hunting!

Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team

Security for the people

September 18, 2014

Cross-posted on the Open Source Blog
A recent Pew study found that 86% of people surveyed had taken steps to protect their security online. This is great—more security is always good. However, if people are indeed working to protect themselves, why are we still seeing incidents, breaches, and confusion? In many cases these problems recur because the technology that allows people to secure their communications, content and online activity is too hard to use.

In other words, the tools for the job exist. But while many of these tools work technically, they don’t always work in ways that users expect. They introduce extra steps or are simply confusing and cumbersome. (“Is this a software bug, or am I doing something wrong?”) However elegant and intelligent the underlying technology (and much of it is truly miraculous), the results are in: if people can’t use it easily, many of them won’t.

We believe that people shouldn’t have to make a trade-off between security and ease of use. This is why we’re happy to support Simply Secure, a new organization dedicated to improving the usability and safety of open-source tools that help people secure their online lives.

Over the coming months, Simply Secure will be collaborating with open-source developers, designers, researchers, and others to take what’s there—groundbreaking work from efforts like Open Whisper Systems, The Guardian Project, Off-the-Record Messaging, and more—and work to make them easier to understand and use.

We’re excited for a future where people won’t have to choose between ease and security, and where tools that allow people to secure their communications, content, and online activity are as easy as choosing to use them.

Posted by Meredith Whittaker, Open Source Research Lead and Ben Laurie, Senior Staff Security Engineer

Cleaning up after password dumps

September 10, 2014

We found that less than 2% of the username and password combinations might have worked, and our automated anti-hijacking systems would have blocked many of those login attempts. We’ve protected the affected accounts and have required those users to reset their passwords.
It’s important to note that in this case and in others, the leaked usernames and passwords were not the result of a breach of Google systems. Often, these credentials are obtained through a combination of other sources.
For instance, if you reuse the same username and password across websites, and one of those websites gets hacked, your credentials could be used to log into the others. Or attackers can use malware or phishing schemes to capture login credentials.

We’re constantly working to keep your accounts secure from phishing, malware and spam. For instance, if we see unusual account activity, we’ll stop sign-in attempts from unfamiliar locations and devices. You can review this activity and confirm whether or not you actually took the action.

A few final tips: Make sure you’re using a strong password unique to Google. Update your recovery options so we can reach you by phone or email if you get locked out of your account. And consider 2-step verification, which adds an extra layer of security to your account. You can visit g.co/accountcheckup where you’ll see a list of many of the security controls at your disposal.

Posted by Borbala Benko, Elie Bursztein, Tadek Pietraszek and Mark Risher, Google Spam & Abuse Team

Gradually sunsetting SHA-1

September 5, 2014

Cross-posted on the Chromium Blog
since at least 2005Collision attacks against SHA-1 are too affordableBaseline Requirements for SSLNISTthe MD5 hash algorithmfrom leading vendorsscrambling for updates
Chrome 39 (Branch point 26 September 2014)

Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is used to highlight other deprecated and insecure practices, such as passive mixed content.

Chrome 40 (Branch point 7 November 2014; Stable after holiday season)

Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.

The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.

Chrome 41 (Branch point in Q1 2015)

Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.

The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer

That’s not the download you’re looking for...

August 14, 2014

Cross-posted on the Chrome Blog
Safe Browsing

these tips

Posted by Moheeb Abu Rajab, Staff Engineer, Google Security

Protecting Gmail in a global world

August 12, 2014

Last week we announced support for non-Latin characters in Gmail—think δοκιμή and 测试 and みんな—as a first step towards more global email. We’re really excited about these new capabilities. We also want to ensure they aren’t abused by spammers or scammers trying to send misleading or harmful messages.
Scammers can exploit the fact that ဝ, ૦, and ο look nearly identical to the letter o, and by mixing and matching them, they can hoodwink unsuspecting victims.* Can you imagine the risk of clicking “ShဝppingSite” vs. “ShoppingSite” or “MyBank” vs. “MyBɑnk”?

To stay one step ahead of spammers, the Unicode community has identified suspicious combinations of letters that could be misleading, and Gmail will now begin rejecting email with such combinations. We’re using an open standard—the Unicode Consortium’s “Highly Restricted” specification—which we believe strikes a healthy balance between legitimate uses of these new domains and those likely to be abused.
We’re rolling out the changes today, and hope that others across the industry will follow suit. Together, we can help ensure that international domains continue to flourish, allowing both users and businesses to have a tête-à-tête in the language of their choosing.

Posted by Mark Risher, Spam & Abuse Team

*For those playing at home, that's a Myanmar letter Wa (U+101D), a Gujarati digit zero (U+AE6) and a Greek small letter omicron (U+03BF), followed by the ASCII letter 'o'.

HTTPS as a ranking signal

August 7, 2014

Cross-posted from the Webmaster Central Blog

Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like strong HTTPS encryption by default. That means that people using Search, Gmail and Drive, for example, automatically have a secure connection to Google.

Beyond our own stuff, we’re also working to make the Internet safer more broadly. A big part of that is making sure that websites people access from Google are secure. For instance, we have created resources to help webmasters prevent and fix security breaches on their sites.
We want to go even further. At Google I/O a few months ago, we called for “HTTPS everywhere” on the web.
We’ve also seen more and more webmasters adopting HTTPS (also known as HTTP over TLS, or Transport Layer Security), on their website, which is encouraging.
For these reasons, over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content—while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.
In the coming weeks, we’ll publish detailed best practices (we’ll add a link to it from here) to make TLS adoption easier, and to avoid common mistakes. Here are some basic tips to get started:

Decide the kind of certificate you need: single, multi-domain, or wildcard certificate
Use 2048-bit key certificates
Use relative URLs for resources that reside on the same secure domain
Use protocol relative URLs for all other domains
Check out our Site move article for more guidelines on how to change your website’s address
Don’t block your HTTPS site from crawling using robots.txt
Allow indexing of your pages by search engines where possible. Avoid the noindex robots meta tag

If your website is already serving on HTTPS, you can test its security level and configuration with the Qualys Lab tool. If you are concerned about TLS and your site’s performance, have a look at Is TLS fast yet?. And of course, if you have any questions or concerns, please feel free to post in our Webmaster Help Forums.
We hope to see more websites using HTTPS in the future. Let’s all make the web more secure!

Posted by Zineb Ait Bahajji and Gary Illyes, Webmaster Trends Analysts

Announcing Project Zero

July 15, 2014

Posted by Chris Evans, Researcher Herder
Security is a top priority for Google. We've invested a lot in making our products secure, including strong SSL encryption by default for Search, Gmail and Drive, as well as encrypting data moving between our data centers. Beyond securing our own products, interested Googlers also spend some of their time on research that makes the Internet safer, leading to the discovery of bugs like Heartbleed.
The success of that part-time research has led us to create a new, well-staffed team called Project Zero.
You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications. Yet in sophisticated attacks, we see the use of "zero-day" vulnerabilities to target, for example, human rights activists or to conduct industrial espionage. This needs to stop. We think more can be done to tackle this problem.
Project Zero is our contribution, to start the ball rolling. Our objective is to significantly reduce the number of people harmed by targeted attacks. We're hiring the best practically-minded security researchers and contributing 100% of their time toward improving security across the Internet.
We're not placing any particular bounds on this project and will work to improve the security of any software depended upon by large numbers of people, paying careful attention to the techniques, targets and motivations of attackers. We'll use standard approaches such as locating and reporting large numbers of vulnerabilities. In addition, we'll be conducting new research into mitigations, exploitation, program analysis—and anything else that our researchers decide is a worthwhile investment.
We commit to doing our work transparently. Every bug we discover will be filed in an external database. We will only report bugs to the software's vendor—and no third parties. Once the bug report becomes public (typically once a patch is available), you'll be able to monitor vendor time-to-fix performance, see any discussion about exploitability, and view historical exploits and crash traces. We also commit to sending bug reports to vendors in as close to real-time as possible, and to working with them to get fixes to users in a reasonable time.
We're hiring. We believe that most security researchers do what they do because they love what they do. What we offer that we think is new is a place to do what you love—but in the open and without distraction. We'll also be looking at ways to involve the wider community, such as extensions of our popular reward initiatives and guest blog posts. As we find things that are particularly interesting, we'll discuss them on our blog, which we hope you'll follow.

Security Blog