323976 - experimental calendar.xpi alarm window is vulnerable to spoofing

Status: VERIFIED FIXED

(Calendar :: Security, defect)

Description

[Joey Minta]

We've been having a large amount of discussion lately about the relevant security issues surrounding nsIWindowWatcher's getWindowByName and nsIWindowMediator's getMostRecentWindow.  The conclusion is basically that getWindowByName can be spoofed by malicious websites that create windows with the same name.  getMostRecentWindow will only return top-level windows that work based on type, and is therefore safe.  Sunbird itself doesn't display any websites, so it's not vulnerable, but installing the experimental calendar.xpi into firefox would expose a hole.  
As far as I can see, the vulnerability only would allow a malicious website to learn the contents of your private events, although it may be possible to also create some sort of priviledge elevation issue, too.

Sunbird 0.2 and the equivalent xpi used getMostRecentWindow and are therefore not vulnerable.

Patch to follow.  We need to decide how forceful we want to be about getting current users of the experimental xpi to upgrade to a newer version after this is solved.

Comment 1

[Joey Minta]

Attachment: patch v1

dmose has been following along in the discussions, asking him for review.  (The patch is largely the same as the one on bug 299847.  I only broke this out because it's active in the calendar.xpi)

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 208937 [details] [diff] [review]
patch v1

r=dmose.  The first thing the old code did was to call gAlarmWindow.focus(), but (presumably) with chrome priviledges.  Assuming I'm correct (perhaps dveditz can comment), I'd say this is a big deal.

Comment 3

[Joey Minta]

patch checked in.  Now, what's the best strategy for getting this out there?

Comment 4

[Daniel Veditz [:dveditz]]

Does your extension turn off xpc wrappers? In Gecko 1.8 chrome windows should only be interacting with the true native focus() unless you've done something explicit to unwrap the content document.

There may be an issue if your chrome caller is loaded in a browser content window (just filed bug 324074), but I think the calendar extension should be safe. Best to make this change though, it'd still be bad to get the wrong window regardless of whether it's exploitable.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #4)
> Does your extension turn off xpc wrappers? 

As far as I know, it does not.  mvl might know otherwise, however.

> In Gecko 1.8 chrome windows should only be interacting with the true
> native focus() unless you've done something explicit to unwrap the content
> document.

What about function names that are not shadowed by anything in the window object?  i.e. right after it calls focus, it calls addAlarm....

Comment 6

[Boris Zbarsky [:bzbarsky]]

> What about function names that are not shadowed by anything in the window
> object?

Those will end up called on the XPCNativeWrapper, not the underlying Window.