Open Bug 1272610 Opened 9 years ago Updated 4 years ago

Investigate unsafe use of channel.notificationCallbacks

Categories

(Core :: Networking, defect, P5)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

People

(Reporter: jduell.mcbugs, Unassigned)

Details

(Whiteboard: [necko-backlog])

We suspect that we QI (or GetInterface) the callbacks off-main thread (Patrick tells me this happens for any HTTPS channel during TLS setup). And yet it's possible for addons or other JS to implement the channel callbacks (the AdBlock plus author describes using it for tracking redirects here: http://stackoverflow.com/questions/11206967/tracking-the-redirection-path-of-urls-in-javascript ). We had a bug 12 years ago :) to add some automated way to proxy off-main use of callbacks, but we wound up closing it 4 years ago when bsmith claimed we have no more off-main usages. See bug 243591. I think it's worth doing 1) a code audit for this, and 2) write some tests (run an xpcshell HTTPS channel that replaces the callbacks with JS--maybe we have one already? Maybe also run an addon for a week in your browser that replaces the callbacks and simply proxies QI/GetInterface to the "real" callbacks) to see if we're actually OK here or not.
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.