Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Google Businesses Internet Explorer The Internet IT

Google Fixes IE Bug 225

aussie_a writes "Without accepting blame Google has quickly patched the vulnerability, without requiring users to download a patch. Previously covered by Slashdot, the flaw allowed people to access files and passwords on a computer via any website when viewed with IE while running Google Desktop." From the article: "'Google was able to address the problem quickly because it didn't require changing any code at the user's desktop,' MacDonald said. 'Google applied more stringent security controls on its main site, which shut down the exploit.' The incident does raise important questions about Google as a desktop software vendor and its plans for rolling out future security fixes, said MacDonald. "
This discussion has been archived. No new comments can be posted.

Google Fixes IE Bug

Comments Filter:
  • Misleading title (Score:4, Informative)

    by HishamMuhammad ( 553916 ) on Tuesday December 06, 2005 @10:25AM (#14193065) Homepage Journal
    The title sounds as if Google had fixed a bug in Internet Explorer's code. Shouldn't it be "Google fixes Google Desktop bug"?

    Granted, it does make it sound less like news... but I suppose it's because it isn't, really. You don't see stories like "Adobe fixes Photoshop bug", "KDE team fixes Konqueror bug", etc... since of course that's just part of the daily life in development.
  • by TCFOO ( 876339 ) on Tuesday December 06, 2005 @10:30AM (#14193102)
    They fixed their code so that their Desktop Search program couldn't be used maliciously because of a flaw in IE.
  • by kclittle ( 625128 ) on Tuesday December 06, 2005 @10:31AM (#14193114)
    If I RTFA correctly, they just avoided using it. The vulnerability (in IE, which only MS can patch) is still there...

  • Ok everyone.... (Score:5, Informative)

    by brunes69 ( 86786 ) <[slashdot] [at] [keirstead.org]> on Tuesday December 06, 2005 @10:32AM (#14193120)
    This article summary, and also most comments posted so far, are total misinformed garbage.

    First of all, Google did not fix an IE bug. All they did is make their own software a bit more tight in security, so that *they* are not suceptible to the IE bug. It does not *fix* it.

    Second of all, the bug was *not* in Google Desktop, it *is* an IE bug, it just happens that people who use Google Desktop are vulnerable to it since it embeds IE.

    But *ANY* app that embeds IE is (and remains) vulnerable, including many other pieces of software. For example, for all you poker players, if you have an account a UltimateBet [ultimatebet.com], you *are* vulnerable to ths bug, and in theory someone could use it to steal your account information, which is very dangerous, since they may be able th initate withdraws from your account as well.

    This is just the tip of the iceburgm there are literally hundreds of apps that embed the IE engine for rendering. All are at risk.

  • by TheRealMindChild ( 743925 ) on Tuesday December 06, 2005 @10:32AM (#14193121) Homepage Journal
    I think the problem was that the google's software was being run in the "Local Zone", which is almost always highly trusted. The flaw was that a site on the Internet could manipulate the toolbar. Sort of like an XSS vulnerability.
  • by nicc777 ( 614519 ) on Tuesday December 06, 2005 @10:32AM (#14193122) Homepage Journal
    From the article: "Even though Internet Explorer is the root cause of the vulnerability, Google's changing its Desktop Search so that it was no longer remotely accessible though the vulnerability in IE was the responsible thing for Google to do," said Gartner Research vice president Neil MacDonald.
  • Re:Misleading title (Score:5, Informative)

    by skyhawker ( 234308 ) on Tuesday December 06, 2005 @10:46AM (#14193234) Homepage
    The title sounds as if Google had fixed a bug in Internet Explorer's code. Shouldn't it be "Google fixes Google Desktop bug"?

    Not really. The flaw is in IE and Google's use of CSS exposed it to their users. They were able to change their use of CSS to work around the exploit, but the exploit still remains in IE. Even Microsoft admits that.
  • Re:Ok everyone.... (Score:1, Informative)

    by dr.newton ( 648217 ) on Tuesday December 06, 2005 @10:48AM (#14193250) Homepage
    I'm glad you pointed out the distinction between fixing a bug and preventing someone to exploit it using a particular piece of software, but I thought I should in turn point out that Google Desktop does not "embed IE" - I use it fine with firefox. It's just an app that runs locally intercepting google queries by ANY web browser and modifying the data google sends back to you, adding the "Desktop" link to the main page, for example, and performing local hard drive searches.

    It does not embed any html renderer - it doesn't render html at all. It is an application that uses html and javascript to present a GUI, and then the browser does the rendering just like it does for any other page. Google Desktop is just another website to the browser.
  • by palad1 ( 571416 ) on Tuesday December 06, 2005 @10:54AM (#14193291)
  • by Anonymous Coward on Tuesday December 06, 2005 @11:02AM (#14193338)
  • Re:Misleading title (Score:3, Informative)

    by masklinn ( 823351 ) <.slashdot.org. .at. .masklinn.net.> on Tuesday December 06, 2005 @11:03AM (#14193344)
    Shouldn't it be "Google fixes Google Desktop bug"?

    No, because it was not a bug in Google Desktop but a bug in IE that allowed the abuse of the Google Desktop software (and others, BTW).

    Google changed part of their server software to remove the ability to use GDesktop the way it was used, but the flaw in MSIE is still there...

  • Re:Ok everyone.... (Score:3, Informative)

    by masklinn ( 823351 ) <.slashdot.org. .at. .masklinn.net.> on Tuesday December 06, 2005 @11:06AM (#14193365)

    Google, of all organisations, should know better than to trust IE for anything.

    Would it be so hard for them to include a safer rendering engine? Gecko's good. KHTML's good. Both are free. Couldn't they have used those instead? Then if there were any bugs discovered, Google (having the source code) could fix 'em, rather than having to implement some workaround because Microsoft won't.

    Embedding the MSHTML engine in a Win32 application (or using a framework that wraps the controls) takes a few seconds and requires no code integration at all, while using the Gecko engine takes a bit more work.
  • You're 1/2 right (Score:4, Informative)

    by brunes69 ( 86786 ) <[slashdot] [at] [keirstead.org]> on Tuesday December 06, 2005 @11:26AM (#14193495)
    Yes, a large part of Google Desktop will run in any browser.

    But parts of the Sidebar component are rendered using an IE rendering engine. It is simple to verify if you check the references in the EXE and DLLs.

  • by Flyboy Connor ( 741764 ) on Tuesday December 06, 2005 @11:46AM (#14193659)
    The problem is that a browser with ActiveX activated can NEVER be secure. An ActiveX control is simply a Windows executable, which can do anything on the user's machine that Windows can do. And since the app you mention relies on ActiveX, Microsoft will never able to solve your problem.
  • Re:Ok everyone.... (Score:3, Informative)

    by palad1 ( 571416 ) on Tuesday December 06, 2005 @12:01PM (#14193814)
    I beg to differ, it uses the Internet Explorer ActiveX for its sidebar panels.
  • by zootm ( 850416 ) on Tuesday December 06, 2005 @12:04PM (#14193834)

    Well, to be fair, it is extremely comparable to a Firefox extension or plugin, which have similar rights. I don't think there's really a browser which is safe from this.

    I'm not sure what the particular problem with ActiveX is other than the fact that its security model, particularly in old versions, was just pitifully weak (there just wasn't enough forcing people to check a component before installing it). If there's more specific problems, though, I'd like to hear them (always interested).

  • by Anonymous Coward on Tuesday December 06, 2005 @12:12PM (#14193898)
    Uhmm, not quite. We blame the one who did not do as they should have done. The reason we do not blame the compiler for a buffer overflow is the fact that the overflow resulted because the compiler acted the way it is supposed to. Instead, we blame the programmer who was not aware of this. So far, you're right.

    What would you to if your program used libfoo, and libfoo turns out to have a security vulnerability in one of the functions you use? You either update to a new version of libfoo, or you try to restructure your code to avoid using the problematic function.

    In this case, it would seem that Google made use of IE as it was supposed to (by API specification), but IE was not secure as it should have been, so Google decided to do it a different way. I do not see how the fault lies with Google, nor why they deserve particular praise. They found out that one of their underlying programs had a security vulnerability with no known fix, so they used a workaround to secure their application.

    Microsoft on the other hand just gets a "stupid!" from me for allowing something so easily fixed to blow up in their faces like this. Way too much bad press for such a little thing.
  • by matangillon ( 936587 ) on Tuesday December 06, 2005 @12:24PM (#14194006) Homepage
    I'd like to clear up some of the confusion the mainstream media has caused.

    The bug I found is in Microsoft Internet Explorer and not in Google Desktop. This bug remains in the browser and it is in no way fixed. This bug by itself is a pretty serious one and allows for exploitation of many sites that are not Google related.

    My proof of concept code exploited Google Desktop to retrieve private information from a local machine. In order to do that I used the IE bug twice. First I used it on one of Google's sites in order to get a valid key so I can access the local web server that is Google Desktop's interface. The second time was to execute a query on the GDS server and retrieve the results.

    Google basically found a quick hack that nullifies the first portion of the exploit, getting the valid key. They added the following piece of HTML code to their sites, right before the "Desktop" link is revealed: "<!--"/*"/*-->". This makes the IE CSS parser think the rest of the page is a comment so the link won't be visible while trying to read the CSS text.

    The bug in IE remains at large. And GDS itself is still exploitable. If somebody found an XSS hole in one of Google's sites, he would be able to retrive the GDS key and then use the second portion of the exploit to retrieve local results.

    As I said in my original article, this is a serious bug and there's no simple solution for it, at least until IE is fixed.

    Matan
  • by qray ( 805206 ) on Tuesday December 06, 2005 @01:36PM (#14194671)
    Google Desktop apparently uses some CSS style sheets served by their site. The IE vulnerability was in its CSS logic and thus adjusting the CSS on their server avoids the exploit from the Google Desktop vector.
    --
    Q
  • No, *you* RTFA (Score:3, Informative)

    by brunes69 ( 86786 ) <[slashdot] [at] [keirstead.org]> on Tuesday December 06, 2005 @01:48PM (#14194769)
    The whole bug is that there is a XSS vulnerability within the IE JavaScript engine around CSS imports. The vulnerability will let you load the contents of any other site into your own site and examin them. This is normally not allowed.

    All the stuff you are describing is just details around how to use this exploit to get information from Google Desktop. But you can easily do the same thing to exploit any service who uses an embedded IE component to render data from a server, be it internal or external.

    Take my Ultimate Bet example for instance. All you would need to do is have a webpage with the rogue code in it visited by the user at the same time they are logged into Ultimate Bet. You can then use the exploit to load up the user's account page (which will load fine, since they are already logged in), and get whatever the hell data you want, including withdrawing money from their account.

    It's a very dangerous scenario. Someone could write a whole bunch of rogue scripts that looked for various exploitable applications to steal data, that all execute from one page. If the user happened to be running the app at that time they would be instantly screwed by visiting that page. The only reason Google Desktop is a particularly interesting target is that it is *always* running. But that is not a prerequisite for the exploit.

2.4 statute miles of surgical tubing at Yale U. = 1 I.V.League

Working...