Disclosure timeline for vulnerabilities under active attack

Posted by Chris Evans and Drew Hintz, Security Engineers

We recently discovered that attackers are actively targeting a previously unknown and unpatched vulnerability in software belonging to another company. This isn’t an isolated incident -- on a semi-regular basis, Google security researchers uncover real-world exploitation of publicly unknown (“zero-day”) vulnerabilities. We always report these cases to the affected vendor immediately, and we work closely with them to drive the issue to resolution. Over the years, we’ve reported dozens of actively exploited zero-day vulnerabilities to affected vendors, including XML parsing vulnerabilities, universal cross-site scripting bugs, and targeted web application attacks.

Often, we find that zero-day vulnerabilities are used to target a limited subset of people. In many cases, this targeting actually makes the attack more serious than a broader attack, and more urgent to resolve quickly. Political activists are frequent targets, and the consequences of being compromised can have real safety implications in parts of the world.

Our standing recommendation is that companies should fix critical vulnerabilities within 60 days -- or, if a fix is not possible, they should notify the public about the risk and offer workarounds. We encourage researchers to publish their findings if reported issues will take longer to patch. Based on our experience, however, we believe that more urgent action -- within 7 days -- is appropriate for critical vulnerabilities under active exploitation. The reason for this special designation is that each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised.

Seven days is an aggressive timeline and may be too short for some vendors to update their products, but it should be enough time to publish advice about possible mitigations, such as temporarily disabling a service, restricting access, or contacting the vendor for more information. As a result, after 7 days have elapsed without a patch or advisory, we will support researchers making details available so that users can take steps to protect themselves. By holding ourselves to the same standard, we hope to improve both the state of web security and the coordination of vulnerability management.

Changes to our SSL Certificates

Posted by Stephen McHenry, Director of Information Security Engineering

Protecting the security and privacy of our users is one of our most important tasks at Google, which is why we utilize encryption on almost all connections made to Google.

This encryption needs to be updated at times to make it even stronger, so this year our SSL services will undergo a series of certificate upgrades—specifically, all of our SSL certificates will be upgraded to 2048-bit keys by the end of 2013. We will begin switching to the new 2048-bit certificates on August 1st, to ensure adequate time for a careful rollout before the end of the year. We’re also going to change the root certificate that signs all of our SSL certificates because it has a 1024-bit key.

Most client software won’t have any problems with either of these changes, but we know that some configurations will require some extra steps to avoid complications. This is more often true of client software embedded in devices such as certain types of phones, printers, set-top boxes, gaming consoles, and cameras.

For a smooth upgrade, client software that makes SSL connections to Google (e.g. HTTPS) must:

• Perform normal validation of the certificate chain;
• Include a properly extensive set of root certificates contained. We have an example set which should be sufficient for connecting to Google in our FAQ. (Note: the contents of this list may change over time, so clients should have a way to update themselves as changes occur);
• Support Subject Alternative Names (SANs).

Also, clients should support the Server Name Indication (SNI) extension because clients may need to make an extra API call to set the hostname on an SSL connection. Any client unsure about SNI support can be tested against https://googlemail.com—this URL should only validate if you are sending SNI.

On the flip side, here are some examples of improper validation practices that could very well lead to the inability of client software to connect to Google using SSL after the upgrade:

• Matching the leaf certificate exactly (e.g. by hashing it)
• Matching any other certificate (e.g. Root or Intermediate signing certificate) exactly
• Hard-coding the expected Root certificate, especially in firmware. This is sometimes done based on assumptions like the following:
• The Root Certificate of our chain will not change on short notice.
• Google will always use Thawte as its Root CA.
• Google will always use Equifax as its Root CA.
• Google will always use one of a small number of Root CAs.
• The certificate will always contain exactly the expected hostname in the Common Name field and therefore clients do not need to worry about SANs.
• The certificate will always contain exactly the expected hostname in a SAN and therefore clients don't need to worry about wildcards.

Any software that contains these improper validation practices should be changed. More detailed information can be found in this document, and you can also check out our FAQ if you have specific questions.

The results are in: Hardcode, the secure coding contest for App Engine

Posted by Eduardo Vela Nava, Security Team

This January, Google and SyScan announced a secure coding competition open to students from all over the world. While Google’s Summer of Code and Code-in encourage students to contribute to open source projects, Hardcode was a call for students who wanted to showcase their skills both in software development and security. Given the scope of today’s online threats, we think it’s incredibly important to practice secure coding habits early on. Hundreds of students from 25 countries and across five continents signed up to receive updates and information about the competition, and over 100 teams participated.

During the preliminary online round, teams built applications on Google App Engine that were judged for both functionality and security. Five teams were then selected to participate in the final round at the SyScan 2013 security conference in Singapore, where they had to do the following: fix security bugs from the preliminary round, collaborate to develop an API standard to allow their applications to interoperate, implement the API, and finally, try to hack each other’s applications. To add to the challenge, many of the students balanced the competition with all of their school commitments.

We’re extremely impressed with the caliber of the contestants’ work. Everyone had a lot of fun, and we think these students have a bright future ahead of them. We are pleased to announce the final results of the 2013 Hardcode Competition:

1st Place: Team 0xC0DEBA5E
Vienna University of Technology, Austria (SGD $20,000)
Daniel Marth (http://proggen.org/)
Lukas Pfeifhofer (https://www.devlabs.pro/)
Benedikt Wedenik

2nd Place: Team Gridlock
Loyola School, Jamshedpur, India (SGD $15,000)
Aviral Dasgupta (http://www.aviraldg.com/)

3rd Place: Team CeciliaSec
University of California, Santa Barbara, California, USA (SGD $10,000)
Nathan Crandall
Dane Pitkin
Justin Rushing

Runner-up: Team AppDaptor
The Hong Kong Polytechnic University, Hong Kong (SGD $5,000)
Lau Chun Wai (http://www.cwlau.com/)

Runner-up: Team DesiCoders
Birla Institute of Technology & Science, Pilani, India (SGD $5,000)
Yash Agarwal
Vishesh Singhal (http://visheshsinghal.blogspot.com)

Honorable Mention: Team Saviors of Middle Earth (withdrew due to school commitments)
Walt Whitman High School, Maryland, USA
Wes Kendrick
Marc Rosen (https://github.com/maz)
William Zhang

A big congratulations to this very talented group of students!