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 http://127.0.0.1:4664/&s=nnnnnnnnnn 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 http://127.0.0.1:4664/&s=nnnnnnnnnn 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.
References:
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 127.0.0.1. 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 127.0.0.1 in the URL with warez.squarefree.com (which resolves to 127.0.0.1).
Solutions: GDS could reject requests where the hostname is not "127.0.0.1" 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 127.0.0.1.
References:
Combining the holes
Once the attacker has script access to http://gds.evil.com:4664/, has gds.evil.com resolving to 127.0.0.1, 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 127.0.0.1 as the hostname, but they continue to work when 127.0.0.1 is replaced by warez.squarefree.com, which resolves to 127.0.0.1.)
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 "127.0.0.1" 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.
