Google Chrome security flaw discovered

[anon]

Google has downplayed reports of a security vulnerability in its newly-launched Chrome web browser.

Within a day of Chrome's launch, security researchers reported that Chrome had the same auto-download flaw as Apple's Safari web browser.

They said Chrome was developed using the same open-source WebKit rendering engine, and also allowed files to be downloaded automatically to the desktop.

Safari originally did not ask users' permission to download files, which meant malicious code could be dumped on desktops in so-called carpet bomb attacks.

Google Chrome security flaw discovered | 4 Sep 2008 | ComputerWeekly.com

[Aurion]

I guess they need to work their a$$ up harder than that just to prove that they really did a good job & not waste their yet new project right into the drain

[anon]

Well, they did do a good job - but should have started from the WebKit codebase where this bug had already been fixed

[Aurion]

yeah but I don't think it existed at the first place when they coded the browser,I mean it surely showed up right after the release was out

[anon]

No - Safari, whose engine Chrome uses, had already fixed the issue before Chrome itself was out...
Wonder why Google chose to use an old codebase -_-

[vDD+wR]

maybe the google developers started coding chrome parallel to safari and therefore used the old codebase at that time...
but that wouldn't explain why they implemented an up to date java engine and not the old one too...

who knows...

[anon]

Yes, it's a mistery...

The "carpet bomb" bug, revealed by researcher Nitesh Dhanjani in early May and named for the way it could be used to dump files onto the Windows desktop, stemmed from the fact that Safari did not require a user's permission to download a file. Attackers, Dhanjani said, could populate a malicious site with rogue code that Safari would automatically download to the desktop, where it might tempt a curious user into opening the file.

After first balking -- for a time it refused the classify the flaw as a security vulnerability -- Apple patched the bug in mid-June by updating Safari to 3.1.2.

But Google used a pre-patch version of WebKit to build Chrome, and so the bug, which was also patched in later editions of WebKit, slipped through. According to Raff, the Chrome beta uses the older WebKit 525.13, the engine used by Safari 3.1.

Update

I don't know if the bug is fixed in the latest Chrome version, but a workaround exists:

Users can set an option in Chrome that will thwart Raff's exploit by popping up a warning asking for a filename and location for any downloaded file. To change Chrome, select Options under the "Customize and control Google Chrome " menu; the menu is at the far right, near the top, and although not named, looks like a small wrench. Next, click the "Minor Tweaks" tab in the Options window, then check the box that reads "Ask where to save each file before downloading."

[vDD+wR]

lol, its quite kind of funny to see how google messed up the beta..
i mean, this security hole for example had to be found by the chrome developers or testers...

I don't know if the bug is fixed in the latest Chrome version, but a workaround exists:

quite a funny imagination: chrome installation takes about 1 minute, and fixing the security holes by yourself about an hour or two, lol... but pretty frustrating that we really have to do it..

[Logitech]

watch out

<title></title>

[anon]

lol, its quite kind of funny to see how google messed up the beta..
i mean, this security hole for example had to be found by the chrome developers or testers...

I agree, it should have been found... I mean, the bug with the extremely long TITLE or A HREF tags isn't new: IE4 has had it before with IMG (MS worked around it by not displaying an image if its width and height properties are too big, I think).

quite a funny imagination: chrome installation takes about 1 minute, and fixing the security holes by yourself about an hour or two, lol... but pretty frustrating that we really have to do it..

We also need to remove the unique ID from Local State.tmp every time Chrome is started
Mmm no, I'd better stick with Opera for now

[vDD+wR]

We also need to remove the unique ID from Local State.tmp every time Chrome is started

yeah very annoying.. but isnt there a possibility that the .tmp file didn't get deleted after you close the browser? and then turn on the write-protection, so that you have to do just once when starting it for the first time?


greetz

[anon]

but isnt there a possibility that the .tmp file didn't get deleted after you close the browser? and then turn on the write-protection, so that you have to do just once when starting it for the first time?

It's easy to ignore write-protection

But actually, now I think about it, it's possible to make a .bat to possibly automate this: it would always keep a copy of a callhome-free file under a different name; start Chrome, wait a bit, then use that file to replace the .tmp that's just been created.
It may work!

[vDD+wR]

But actually, now I think about it, it's possible to make a .bat to possibly automate this: it would always keep a copy of a callhome-free file under a different name; start Chrome, wait a bit, then use that file to replace the .tmp that's just been created.
It may work!

thought already of a .bat file too, but nevertheless you have to access everytime the .bat which will be pretty depressing too after a time

but its better than nothing, for sure!

It's easy to ignore write-protection

didn't know that.. i thought that when i tick the box then this is the final say.

[anon]

thought already of a .bat file too, but nevertheless you have to access everytime the .bat which will be pretty depressing too after a time

...

You can make a shortcut to the .bat and launch Chrome through it instead, that's less depressing

didn't know that.. i thought that when i tick the box then this is the final say.

No, not really: after all, if you try to delete a read-only file, the only thing Windows will do to thwart your attempt is (re)confirming whether you want to proceed

[vDD+wR]

You can make a shortcut to the .bat and launch Chrome through it instead, that's less depressing

thats a smart idea, to combine both into one shortcut! if thats possible, then it would be the great compromise

No, not really: after all, if you try to delete a read-only file, the only thing Windows will do to thwart your attempt is (re)confirming whether you want to proceed

LOL

typical of windows....