Security holes in Google Desktop Search fixed

Google recently fixed several holes in Google Desktop Search that I found. This is the email I sent to security@google.com to report the holes:

This combination of security holes in mulitple products allows an attacker to read text files indexed and cached by Google Desktop Search. Its success rate is proportional to the amount of time the attacker can keep the victim on the attacker's site and the victim's CPU speed. I think all parts of this attack would work against both Firefox and Internet Explorer, but I've only tested part 1 and only in Firefox.

Recover the URL for the home page of Google Desktop Search

The URL for the front page of Google Desktop Search is for some 10-digit string nnnnnnnnnn. If the string is incorrect, GDS returns a page that says "Invalid Request". This seems to be a second line of defense against XSS and CSRF attacks.

Most browsers have information leaks that allow web scripts to determine whether a link is visited. The attacker assumes that the user has visited the GDS start page with the correct value for nnnnnnnnnn recently enough that the URL is in the browser's global history. Based on my experiments and calculations, it would take several days of CPU time for a script in an untrusted web page in Firefox to find out which of the 10^10 links of the form is visited. An attacker might try to keep a victim on a page for several days, or might try to keep a large number of users on his site for a shorter peroid of time. I don't know what algorithm generates the value nnnnnnnnnn, so I don't know if it has weaknesses that might allow the attacker's script to test fewer than 10^10 URLs.

Solutions: GDS could use a longer salt, to make iterating through every possible salt value harder. GDS could restrict salts to single use, but I think this would break too many things. Firefox (and other browsers) could plug the information leaks in global history.


Perform a Princeton DNS attack

First, make gds.evil.com resolve to an IP under the control of the attacker, with a short TTL. Make the victim load http://gds.evil.com:4664/, which contains a script. Then make gds.evil.com resolve to The script then creates an iframe that loads http://gds.evil.com:4664/&s=nnnnnnnnnnn and uses cross-frame scripting to control the page served by GDS.

You can check that GDS does not prevent this part of the attack by loading GDS and then replacing in the URL with warez.squarefree.com (which resolves to

Solutions: GDS could reject requests where the hostname is not "" or "localhost" (IMO, the HTTP protocol requires it to do so). Firefox, Windows XP, the Windows XP firewall, or my ISP could prevent "external" DNS names from resolving to "internal" IP addresses.like


Combining the holes

Once the attacker has script access to http://gds.evil.com:4664/, has gds.evil.com resolving to, and knows the hash for the home page, he can search for text files and view cached text files. (The links to cached text files are absolute and have as the hostname, but they continue to work when is replaced by warez.squarefree.com, which resolves to

I sent this email on Feb 13, 2005. The first part was fixed in version 20050227 by making the salt longer. The second part was fixed in version 20050325 by making GDS reject requests with hostnames other than "" and "localhost". Google started pushing the updated version to existing users on June 2, 2005, so most users should be upgraded by now. You can see what version of GDS you have by clicking "About".

This is not the same as the hole found by Rice students (Slashdot article), which had been fixed previously.

5 Responses to “Security holes in Google Desktop Search fixed”

  1. Larry Page Says:

    Just what was the objective behind this post? So you could claim some credit?

    Happy Ego Trip!

  2. David 'Zanchey' Adam Says:

    Jesse –

    “Firefox, Windows XP, the Windows XP firewall, or my ISP could prevent “external” DNS names from resolving to “internal” IP addresses.like”

    If Firefox and Windows XP did this (and possibly the firewall), you’d break those wonderful hosts files filled with ad-server to mappings (misguided though they might be).

    I think the first suggestion, GDS rejecting requests that don’t have a host header of localhost or, is the better one.

  3. Adam Says:

    You don’t need a hosts file like that if you have Adblock

  4. Felipe Gomes Says:

    Jesse. what was the solution for bug 57351? It seems like a hard problem to solve..

  5. Jesse Ruderman Says:

    It hasn’t been fixed, but David Baron has been working on it on and off. See https://bugzilla.mozilla.org/show_bug.cgi?id=147777.