Calls to nsScriptNameSetRegistry::AddExternalNameSet expose native components to JavaScript. This introduces security holes because at least some of these native services expose powerful operations to web JavaScript. Here are the current list of calls to AddExternalNameSet in mozilla: /silentdl/nsSilentDownload.cpp, line 338 -- registry->AddExternalNameSet(nameSet); (dougt) /xpinstall/src/nsSoftwareUpdate.cpp, line 419 -- scriptNameSet->AddExternalNameSet(this); (dougt) /layout/build/nsLayoutModule.cpp, line 223 -- gRegistry->AddExternalNameSet(nameSet); (kipp) /xpfe/AppCores/src/nsAppCoresManager.cpp, line 196 -- registry->AddExternalNameSet(nameSet); (rods) /xpfe/appshell/src/nsAppShellService.cpp, line 195 -- registry->AddExternalNameSet(nameSet); (rpotts)

The occurance you have attributed to me is actually vidur's, so I'm removing myself from the list.

nsSilentDownload is not being used anymore. Maybe in 5.1, and by that time, we may do it a bit different. nsSoftwareUpdate exposes two objects into the web javascript. The first is InstallVersion, and the second is InstallTrigger. Both are needed for XPInstall (aka SmartUpdate). A review of the security of these exposed APIs may be needed. Norris, should you be the person to do this?

doug, Thanks for the clarification. Yes, I'd be the one to review the exposed APIs. I've opened 16329 for the security review for these two objects.

Not required for beta.

Push security review tasks off until M16.

Bulk moving all Browser Security bugs to new Security: General component. The previous Security component for Browser will be deleted.

Changing Qa contact to myself.

removing self from cc list

Bulk reassigning most of norris's bugs to mstoltz.

Security reviews and denial-of-service attacks. These will be addressed in the post-beta2 timeframe (unless someone's interested in tackling them earlier?)

Assigning QA to czhang

nsbeta3/p4

We saw this rated as P4. Is this a denial of service attack? If so, we need to minus it for PR3/RTM. Otherwise, we need better description. Thanks, Jim

It's not an attack, but a necessary security review. There's only a handful of call sites which need to be reviewed.

It could be a lot worse than a DOS -- any of those objects might be exploitable in nasty ways. InstallTrigger is a potential privacy problem, for example, though equivalent functionality existed in 4.x and it can be turned off.

Marking security reviews as rtm.

Removing nsbeta3 to make queries clearer.

You're not supposed to be removing milestone keyword "nominations" as the fact of nomination carries information. Instead you should have lobbied the relevant managers/pdt memebers to mark it [nsbeta3-]

vidur, rpotts, and rods never commented on their uses of this. dougt's appear to be benign since there's a pref to turn them off. Do we have a story on the rest?

PDT marking [rtm-] because there isn't a real bug described here -- only a potential bug. Clayton to follow up with mitch in case there's an actual exploit here.

Mass changing QA to ckritzer.

Milestone 0.8 has been released. We should either resolve this bug or update its milestone.

Mass adding mozilla0.9 keyword (mass changing milestone doesn't seem to work).

Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

don't move bugs that are in the 1.0 dependency tree. sorry.

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

Clearing milestone for now.

*** This bug has been marked as a duplicate of 7262 ***