Google

Google is rolling out a patch on their servers to fix the Google calendar and contacts sidejacking issue we talked about in a recent Sunday editorial.  This will require no user action, and even your carrier won't be able to stop it so they can put Bing on it first.

To review: there is a bug (that was fixed in Gingerbread) that lets an attacker have potential access to your Google calendar, contacts, and Picasa account if you log in on an unsecure Wifi network.  Because there are about a gazillion phones affected, and many of them will never see Gingerbread, the server-side fix is welcomed.

We don't know the exact details of the fix, but a statement by Google says:

Today we’re starting to roll out a fix which addresses a potential security flaw that could, under certain circumstances, allow a third party access to data available in calendar and contacts. This fix requires no action from users and will roll out globally over the next few days.

We still say the bug should have never made it out to users in the first place, but a speedy resolution is always good.  Just don't forget about Picasa while you're playing in the server code, Google.

Source: AllThingsD

 

Reader comments

Google rolling out server-side fix for Android sidejacking issue

16 Comments

This is good news. Do these fixes come as updated Google apps (calendar, contacts), or is this a change to the core android OS? The only reason I ask is that I am curious about what Google can do directly.

This is good news. Do these fixes come as updated Google apps (calendar, contacts), or is this a change to the core android OS? The only reason I ask is that I am curious about what Google can do directly.

Not speedy, if the updated Android to workaround the bug then its been many months. Flaw publicity works every time...

Unless I'm misunderstanding something, a "server-side fix" is a change at the server - no pushing to devices is involved.

But I have to say that passing credentials over an insecure connection doesn't qualify as a bug in my book - it falls into the somebody-didn't-know-what-they-were-doing category, and violates the most basic of security practices.

Agree but I'd say, 'knew what they were doing and didn't care'. The Twitter and Facebook apps did the same thing.

I suspect Google changed the structure of the token to tie it to a particular device (probably by factoring in the device ID into the generation algorithm) and by shortening the lifetime. These would be good changes. I'd still like to see it send over SSL, but that would likely require client-side changes.

Not necessarily, you can use a redirect to a HTTPS URL that would cause the client to re-request using that protocol. That's more likely than changing the token generation mechanism. If the device ID is sent along with the token to authenticate, that could be captured and spoofed too - ie. no real additional protection.