204 bytes, application/vnd.mozilla.xul+xml
3.57 KB, text/plain
6.66 KB, text/plain
35.13 KB, text/plain
2.21 KB, text/html
33.48 KB, text/plain
1.13 KB, patch
|Details | Diff | Splinter Review|
Created attachment 495755 [details] The file which when opened multiple times would result in the crash at exit.
So you've seen this problem with add-ons OTHER than NoScript (less reliably), and never without addons or in safe-mode?
Sicking: jst says you're the best person to take an initial look at this
Assignee: nobody → jonas
blocking2.0: --- → betaN+
Component: Security → Security
Product: Firefox → Core
QA Contact: firefox → toolkit
Not blocking 2.0 on this as remote xul is disabled which lowers the severity of this bug on trunk.
Whiteboard: [sg:critical?] → [sg:critical?][sg:needinfo]
Status: UNCONFIRMED → NEW
Component: Security → XUL
Ever confirmed: true
QA Contact: toolkit → xptoolkit.widgets
Lowering to [sg:moderate] -- something's wrong here, but it's hard to call it exploitable at this point.
Whiteboard: [sg:critical?][sg:needinfo] → [sg:moderate][sg:needinfo]
Clearing sg: markings for re-triage in light of recent comments
Summary: Use after free when viewing xul document with certain add-ons. → Use after free (in nsXULProtypeScript?) when viewing xul document w/JS disabled
... might still be "moderate" if it only happens with JS disabled, which in practice is rare (but less rare amongst security-aware users).
back to sg:critical for now, "worst case". Won't know for sure until we find the true cause. We might still bump it down if JS is required in all cases, rather than just something that helps us find it in this particular testcase.
Created attachment 517259 [details] [diff] [review] v1 UnlinkJSObjects only calls DropScriptObjects if mScriptObject.mObject is non-null, so we shouldn't call HoldScriptObjects if we're setting mScriptObject.mObject to null since we'll never call DropScriptObjects and we'll end up accessing freed objects.
Attachment #517259 - Flags: review?(jonas)
This relies on remote XUL and on JS being disabled (either through prefs or an addon) because in that case the compilation will return a success code with a null script object. I don't think you can trigger it in any other way.
Attachment #517259 - Flags: review?(jonas) → review+
peterv: worth fixing on m-c? we don't have -remote- XUL, but might this affect our own internal (or add-on) XUL? Not a security bug in those cases, just bugs.
Whiteboard: [sg:critical?] → [sg:critical?] (if JS disabled)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Comment on attachment 517259 [details] [diff] [review] v1 Approved for 220.127.116.11, a=dveditz for release-drivers
blocking1.9.2: needed → .18+
Whiteboard: [sg:critical?] (if JS disabled) → [sg:critical?] (if JS disabled) needs 1.9.2 landing
status1.9.2: wanted → .18-fixed
Whiteboard: [sg:critical?] (if JS disabled) needs 1.9.2 landing → [sg:critical?] (if JS disabled)
You need to log in before you can comment on or make changes to this bug.