Closed Bug 323976 Opened 14 years ago Closed 14 years ago

experimental calendar.xpi alarm window is vulnerable to spoofing

Categories

(Calendar :: Security, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jminta, Assigned: jminta)

Details

Attachments

(1 file)

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.
Attached patch patch v1Splinter Review
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)
Attachment #208937 - Flags: first-review?(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.
Attachment #208937 - Flags: first-review?(dmose) → first-review+
patch checked in.  Now, what's the best strategy for getting this out there?
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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.
(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....
> 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.
Group: security
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.