Google Online Security Blog

Are you using the latest web browser?

16 de julho de 2008

Written by Thomas DuebendorferSlow migration to latest browser version"Understanding the Web Browser Threat"Neglected security patches

Maximum measured share of users surfing the web with the most secure versions of Firefox, Safari, Opera and Internet Explorer in June 2008 as seen on Google websites.Obsolete browser warning

Example "best before" implementation on a Web browser

Meet ratproxy, our passive web security assessment tool

1 de julho de 2008

Posted by Michal Zalewskiratproxyherepage

Safe Browsing Diagnostic To The Rescue

15 de maio de 2008

Posted by Niels ProvosSafe Browsing APISafe Browsing diagnostic page

What is the current listing status for [the site in question]?

We display the current listing status of a site and also information on how often a site or parts of it were listed in the past.

What happened when Google visited this site?

This section includes information on when we analyzed the page, when it was last malicious, what kind of malware we encountered and so fourth. To help web masters clean up their site, we also provide information about the sites that were serving malicious software to users and which sites might have served as intermediaries.

Has this site acted as an intermediary resulting in further distribution of malware?

Here we provide information if this site has facilitated the distribution of malicious software in the past. This could be an advertising network or statistics site that accidentally participated in the distribution of malicious software.

Has this site hosted malware?

Here we provide information if the the site has hosted malicious software in the past. We also provide information on the victim sites that initiated the distribution of malicious software.

interstitialtech report [pdf]

Contributing To Open Source Software Security

5 de maio de 2008

Written by Will Drewryoperating systemsweb browsersSecure Programming for Linux and Unix HOWTO

people need to actually review the code

developers/reviewers need to know how to write secure code

once found, security problems need to be fixed quickly, and their fixes distributed quickly

said beforeregularly submitsecurity testing toolssecurity challengesopen source computer emergency response team

All Your `iFrame` Are Point to Us

11 de fevereiro de 2008

Written by Niels Provos, Anti-Malware Teamdrive-by downloadstechnical report [PDF]Search Results Containing a URL Labeled as Harmful

Browsing HabitsDMOZMalicious Content InjectionGhost In the Browser [PDF]technical report [PDF]
Structural Properties of Malware Distribution

Help us fill in the gaps!

29 de novembro de 2007

Posted by Ian FetteWe've been targeting malware for over a year and a half, and these efforts are paying off. We are now able to display warnings in search results when a site is known to be malicious, which can help you avoid drive-by downloads and other computer compromises. We are already distributing this data through the Safe Browsing API, and we are working on bringing this protection to more users by integrating with more Google products. While these are great steps, we need your help going forward!
Currently, we know of hundreds of thousands of websites that attempt to infect people's computers with malware. Unfortunately, we also know that there are more malware sites out there. This is where we need your help in filling in the gaps. If you come across a site that is hosting malware, we now have an easy way for you to let us know about it. If you come across a site that is hosting malware, please fill out this short form. Help us keep the internet safe, and report sites that distribute malware.

Auditing open source software

8 de outubro de 2007

Written by Chris Evans, Security Team

JDK. In May 2007, I released details on an interesting bug in the ICC profile parser in Sun's JDK. The bug is particularly interesting because it could be exploited by an evil image. Most previous JDK bugs involve a user having to run a whole evil applet. The key parts of code which demonstrate the bug are as follows:

TagOffset = SpGetUInt32 (&Ptr); if (ProfileSize < TagOffset) return SpStatBadProfileDir; ... TagSize = SpGetUInt32 (&Ptr); if (ProfileSize < TagOffset + TagSize) return SpStatBadProfileDir; ... Ptr = (KpInt32_t *) malloc ((unsigned int)numBytes+HEADER);

Both TagSize and TagOffset are untrusted unsigned 32-bit values pulled out of images being parsed. They are added together, causing a classic integer overflow condition and the bypass of the size check. A subsequent additional integer overflow in the allocation of a buffer leads to a heap-based buffer overflow.

gunzip. In September 2006, my colleague Tavis Ormandy reported some interesting vulnerabilities in the gunzip decompressor. They were triggered when an evil compressed archive is decompressed. A lot of programs will automatically pass compressed data through gunzip, making it an interesting attack. The key parts of the code which demonstrate one of the bugs are as follows:

ush count[17], weight[17], start[18], *p; ... for (i = 0; i < (unsigned)nchar; i++) count[bitlen[i]]++;

Here, the stack-based array "count" is indexed by values in the "bitlen" array. These values are under the control of data in the incoming untrusted compressed data, and were not checked for being within the bounds of the "count" array. This led to corruption of data on the stack.

libtiff. In August 2006, Tavis reported a range of security vulnerabilities in the libtiff image parsing library. A lot of image manipulation programs and services will be using libtiff if they handle TIFF format files. So, an evil TIFF file could compromise a lot of desktops or even servers. The key parts of the code which demonstrate one of the bugs are as follows:

if (sp->cinfo.d.image_width != segment_width || sp->cinfo.d.image_height != segment_height) { TIFFWarningExt(tif->tif_clientdata, module, "Improper JPEG strip/tile size, expected %dx%d, got %dx%d",

Here, a TIFF file containing a JPEG image is being processed. In this case, both the TIFF header and the embedded JPEG image contain their own copies of the width and height of the image in pixels. This check above notices when these values differ, issues a warning, and continues. The destination buffer for the pixels is allocated based on the TIFF header values, and it is filled based on the JPEG values. This leads to a buffer overflow if a malicious image file contains a JPEG with larger dimensions than those in the TIFF header. Presumably the intent here was to support broken files where the embedded JPEG had smaller dimensions than those in the TIFF header. However, the consequences of larger dimensions that those in the TIFF header had not been considered.

Information flow tracing and software testing

17 de setembro de 2007

Posted by Will Drewry, Security TeamSrinath's LemonoriginallyWOOT'07paperFlayerdynamic analysis frameworkdownloadcontributionsfeedback

Automating web application security testing

16 de julho de 2007

Posted by Srinath Anantharaju, Security TeamStored XSSReflected XSS

Injection in regular HTML body - angled brackets not filtered or escaped

<b>Your query '<script>evil_script()</script>' returned xxx results</b>

Injection inside tag attributes - double quote not filtered or escaped

<form ...
<input name="q" value="blah"><script>evil_script()</script>">
</form>

Injection inside URL attributes - non-http(s) URL

<img src="javascript:evil_script()">...</img>

In JavaScript context - single quote not filtered or escaped

<script>
var msg = 'blah'; evil_script(); //';
// do something with msg variable
</script>

Update:

The reason behind the "We're sorry..." message

9 de julho de 2007

Posted by Niels Provos, Anti-Malware TeamCAPTCHAsorrysorryACM WORM 2006Search Worms [PDF]Santyfirst post

Security Blog