Slashdot Mirror
Flaw in Google's New Desktop Tool [Update: Fixed!]
silassewell writes "A Rice University computer scientist and two of his students have discovered a potentially serious security flaw [Sell your soul to the NYTimes to Read] in the desktop search tool for personal computers that was recently distributed by Google." Update: 12/21 03:15 GMT by T : An anonymous reader writes "It's being reported that the security problem in Google's Desktop Search has been plugged."
A Rice University computer scientist and two of his students have discovered a potentially serious security flaw in the desktop search tool for personal computers that was recently distributed by Google. The glitch, which could permit an attacker to secretly search the contents of a personal computer via the Internet, is what computer scientists call a composition flaw - a security weakness that emerges when separate components interact. "When you put them together, out jumps a security flaw," said Dan Wallach, an assistant professor of computer science at Rice in Houston, who, with two graduate students, Seth Fogarty and Seth Nielson, discovered the flaw last month. "These are subtle problems, and it takes a lot of experience to ferret out this kind of flaw," Professor Wallach said. Google introduced a test version of the desktop search tool on Oct. 14, and it can be downloaded at no cost. The program indexes material on a user's local hard disk and then blends Web search results with local user information like electronic mail, text documents and other files. The flaw would permit a search to reveal only small portions of the files. The way the software tool is designed, a user's queries, but no locally stored information, is distributed via the Internet. But by reading user queries sent to its search service, Google is able to place its AdWords text advertisements next to the search results displayed in a user's browser window. In a statement over the weekend, the company said that it had been notified of the flaw by the computer researchers in late November and had begun distributing a new version of the desktop search engine that repairs the potential security hole. Google's introduction of a desktop search tool has touched off a competition with its closest Web search service competitors, Microsoft and Yahoo. Microsoft made a test version of its desktop search tool available last Monday as part of its MSN toolbar suite, and Yahoo has said that it will begin testing a similar search tool in January. The Rice University researchers said that they had not yet examined Microsoft's desktop search program, but noted that the service did not appear to integrate Web and local search results in the same manner as the Google tool. The researchers said that the Google security weakness lay in the way that Google Desktop was designed to intercept outgoing network connections from the user's computer. The program looks for traffic that appears to be going to Google.com and then inserts results from a user's hard disk for a particular search. They found that it was possible to trick the Google desktop search program into inserting those results into other Web pages where an attacker could read them. An attack would require a user to visit the attacker's Web site first, and any type of Web browser could make a user vulnerable. Google said there was no evidence that any such attacks had occurred. The Rice group was able to create a Java program that makes network connections back to the computer from where it was downloaded and then make it appear as if it were asking for a search at Google.com. That was enough to fool the Google desktop software into providing the user's search information. The program was able to do anything with the results, including transmitting them back to the attacking site. "This began as a student project to study how Google Desktop worked and to see if there were any security flaws," said Professor Wallach. "We started by wondering how Google did the local search integration. Once we figured out how it worked, it wasn't too much extra work to break it." The researchers said that Google had responded quickly to their alert last month and had begun releasing a corrected version of the program on Dec. 10. The Google desktop program includes an update feature that permits the company to automatically install new versions of the program on users' computers without user intervention or knowledge. The Rice researchers said that it was possible for users to tell if their version of the Google program had been patched by examining the "about" page from the Google Desktop icon in the browser task bar. Version numbers above 121,004 indicate a newer edition of the program.
Here's a reg free link for those of us who have already sold our souls for other devious purposes ;)
Here is the no-subscriber link via Google News, for all that self-referential goodness...
At least they don't bury the bad news...
http://news.com.com/Google+Weve+fixed+desktop+sear ch+tool+flaw/2100-1002_3-5497885.html?tag=nefd.top
Google has already fixed the problem, and if you are using GDS, you should have the updated version since GDS updates automatically without user intervention. If you neeed to check, your version number should be 121,004 (or above). I verified from my firewall that my version was updated yesterday. (Apparently Google has been rolling out the updates since December 10)
"When the only tool you own is a hammer, every problem begins to resemble a nail." - Abraham Maslow (1908-1970)
From the researchers themselves, rather than the NYT's garbled take on it.
"An attack would require a user to visit the attacker's Web site first, and any type of Web browser could make a user vulnerable."
;-)
It seems like most non-email Internet attacks require you to visit an attacker's website before the payload can be delivered (there are some good articles about this at ISC). I would tend to think that unpatched browsers (<cough>IE<cough>) would still cause more problems that this.
Don't misunderstand me, though; I am not trying to excuse Google from the flaw, but the good news is that it's already fixed, and I'm sure the scum of the Internet are going to focus on these other (exciting, money-making) opportunities.
PS. I know Seth Fogarty, does that give me some sort of karma bonus
I think the NY Times article was incorrect regarding which versions are fixed. The research report says 121004 and later are fixed (while NYT says those more recent than 121004 are fixed).
c e.edu/gdesktop-tr-dec04.pdfr acker.com/id?1012624
Read the original research report for a good dissection of Google Desktop Search and how it works.
Here are the URLs for the original summary, the original technical report (PDF), and a SecurityTracker alert:
http://seclab.cs.rice.edu/
http://seclab.cs.ri
http://www.securityt
Stuart
info@securitytracker.com
Perhaps, you guys should try out a free alternative such as DocYouMeant Hound, available at http://myradus.com/.
(Disclaimer: I know the guy who wrote it, but it's a cool program.)
nooo.. it's a fairly common way to find security holes. you can identify every input and every state a program can enter, test all that to be solid, and it can still yield security flaws when working together with another peice of software. This happens most especially on the web, where multiple technologies plug into each other, and unless the sandboxing is extremely solid, a combination of programs noone considered can easily have dastardly results. i think the usefulness of a desktop search tool to any bug looking for targets to infect is pretty obvious. The settings files for the programs are easily mined for info too, if they're not already stored in that abhorrent windows registry.
A web page on the attack is http://seclab.cs.rice.edu/ which also links to a technical report.
The way it works is actually pretty simple. What happens normally is that the toolbar watches your outgoing and incoming web connections. When you make a Google query, it detects that and does a local search of its index of your disk. When the results come back from Google, it mixes in the results from the web with the results from your disk. This design is to protect your privacy.
The attack is for a malicious site to download a Java applet to your system. This applet does a Google query (via the malicious site as a proxy, to defeat applet sandboxing), and then reads the results which come back. When the results get back to the applet they have gone through the Google toolbar and gotten the local disk results integrated. The applet then sends the data to the malicious site, and presto, it knows a lot about the contents of your disk.
Not quite. Again, I recomend checking the webpage , but since I know most of you won't (I wouldn't)... Go install google desktop. Go to google.com. Do a search. Notice it says 'local results found:' and includes small snippets of the local results. We can get those snippets for arbitrary searches by making our own requests to Google. The local data is integrated after the reponse comes back from Google, but before we get it. The only tricky bit is making the requests to google.com through an applet, since the applet is not allowed to connect to google.com, only the originating host. Luckily we can run a web proxy on our originating host and still get the integration results. We don't even have to return the right google.com search result... we can just replay an old page.
from the NYT article:
...The researchers said that Google had responded quickly to their alert last month and had begun releasing a corrected version of the program on Dec. 10....
BTW, CNET reported this last night.
[obligatory jab at microsoft,typical at this point in a comment, is being left as an exercise for the readers....]
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
This is unnecessary. You can disable the integration option, which is a minor feature anyway. Check our webpage
Here is how the attack works.
This is based on Wired's much more clear and coherent description.
Desktop search installs an object that the browser instantiates on Google web pages to render local results along side of google results. No data is sent in this process.
The attack involves the fact that this data is present on the web page itself, and is added to the DOM. An attacker using JavaScript can traverse the DOM and read the exerpts of files shown on the search page.
It cannot follow this to the document itself in the cache, and it can see nothing other than the quoted excerpt.
It's beta software, bound to be problems. This particular problem is because the object isn't "locked to the page."
The vulnerability doesn't effect any other desktop search tool that is currently available, because none of them use an object in the browser to integrate search results with their web page. All the other tools are either search your desktop or search the web, not search both at once.
Using FireFox, without the object, you won't get the integrated search results, so you won't have the problem.
If your code is acting bloated, and is running rather slow, it's likely and predicted that some loops you will unroll.
Check out our webpage . The tone of the article is not Dan's doing. He has been more than generous with the credit, and was involved with our project and of invaluable assistance the entire time.
Admittedly the NYT article is extremely light on details (and those details don't show up until the end of the article), but from what it sounds like, the Google search tool sends a brief chunk of each search result, whether of local or network origin, to Google, so Google can display some ads.
It does sound like that, but that would be a terrible design, wouldn't it? It would mean your private search data is being sent to Google! And Google swore up and down that they wouldn't do this.
Actually, your private results are not sent to Google; rather, when the data comes back from Google, the toolbar mixes your private results into the web search results and passes that on to the browser. The problem is that it may not be the user directing the browser to do the request. It could be a Java applet, or maybe (with some help) some Javascript on a malicious web page. Then the nasty code sees the results and it can send them off to where they shouldn't go.
Applets most definitely can ask for permission to access webservers other than the one that is in their immediate sandbox.
:)
IIRC most jvms assess the risk involved in granting a particular privilege to an applet, and accessing webservers is one of the lower risk permissions - versus socket operations and local filesystem access.
Most users will click yes to anything but the most dire warnings
Here's Rice's security lab post about the flaw: clicky