Closed Bug 478433 Opened 16 years ago Closed 16 years ago

XPCNativeWrapper's toString's __proto__ comes from the wrong scope

Categories

(Core :: XPConnect, defect, P2)

Product:
Core
Component:
XPConnect
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.1

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

Details

(Keywords: fixed1.9.1, verified1.8.1.22, verified1.9.0.9, Whiteboard: [sg:high])

Attachments

(3 files, 1 obsolete file)

Fix for this bug
1.41 KB, patch
jst
: review+
jst
: superreview+
dveditz
: approval1.9.0.9+
Details | Diff | Splinter Review
1.8.0 backport
1.11 KB, patch
jst
: review+
Details | Diff | Splinter Review
for 1.8 branch (attempt 2)
1.48 KB, patch
mrbkap
: review+
dveditz
: approval1.8.1.next+
Details | Diff | Splinter Review
This is a similar problem to bug 370127. If chrome code calls content.toString.call(), then content-defined functions can be called by chrome code. Also, it's possible to use this bug to bypass XOW and perform bug 369334's XSS attack.
Assignee: nobody → mrbkap
Flags: blocking1.9.1?
Flags: blocking1.9.0.8?
Flags: blocking1.8.1.next?
Attached patch Fix for this bug — — Splinter Review
This fixes this bug. I'm re-evaluating how these toString methods are implemented though.
Attachment #362261 - Flags: superreview?(jst)
Attachment #362261 - Flags: review?(jst)
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.8?
Flags: blocking1.9.0.8+
Whiteboard: [sg:high]
Flags: wanted1.8.1.x+
Flags: blocking1.9.1? → blocking1.9.1+
Attachment #362261 - Flags: superreview?(jst)
Attachment #362261 - Flags: superreview+
Attachment #362261 - Flags: review?(jst)
Attachment #362261 - Flags: review+
Flags: blocking1.8.1.next?
Whiteboard: [sg:high] → [sg:high] needs landing
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1
http://hg.mozilla.org/mozilla-central/rev/6b6128b32170
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [sg:high] needs landing → [sg:high]
Comment on attachment 362261 [details] [diff] [review] Fix for this bug This applies as-is to the 1.9.0 branch.
Attachment #362261 - Flags: approval1.9.0.8?
Comment on attachment 362261 [details] [diff] [review] Fix for this bug Approved for 1.9.0.8, a=dveditz for release-drivers
Attachment #362261 - Flags: approval1.9.0.8? → approval1.9.0.8+
Fixed on the 1.9.0 branch.
Keywords: fixed1.9.0.8
Verified for 1.9.0.8 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8pre) Gecko/2009031904 GranParadiso/3.0.8pre. Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090319 Shiretoko/3.5b4pre.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.8 → verified1.9.0.8
Comment on attachment 371857 [details] [diff] [review] 1.8.0 backport Can you please confirm this one?
Attachment #371857 - Flags: review?(jst)
Attachment #371857 - Flags: review?(jst) → review+
Flags: blocking1.8.1.next?
Flags: blocking1.8.0.next?
Attached patch for 1.8 branch (obsolete) — — Splinter Review
this patch fixes both testcases on 1.8; avoided not exported js_SetSlotThreadSafe by using (funobj)->slots[JSSLOT_PARENT] directly. Hope thats the right approach.
Attachment #374793 - Flags: review?(jst)
Whiteboard: [sg:high] → [sg:high] needs r=jst for 1.8.1 (answer "(funobj)->slots[JSSLOT_PARENT]" question)
Comment on attachment 374793 [details] [diff] [review] for 1.8 branch >+ // avoid not exported js_SetSlotThreadSafe >+ (funobj)->slots[JSSLOT_PARENT] = OBJECT_TO_JSVAL(obj); I think you want JS_SetParent(cx, funobj, obj) here.
Attachment #374793 - Flags: review?(jst) → review-
Whiteboard: [sg:high] needs r=jst for 1.8.1 (answer "(funobj)->slots[JSSLOT_PARENT]" question) → [sg:high] needs new 1.8.1 patch
with ::JS_SetParent (see comment 13)
Attachment #374793 - Attachment is obsolete: true
Attachment #378031 - Flags: review?(mrbkap)
Attachment #378031 - Flags: review?(mrbkap) → review+
Comment on attachment 378031 [details] [diff] [review] for 1.8 branch (attempt 2) >+ // avoid not exported js_SetSlotThreadSafe >+ JS_SetParent (cx, funobj, obj); I don't think the code comment is necessary, and get rid of the space before the paren (not that it matters, it's your branch!).
Flags: blocking1.8.1.next? → blocking1.8.1.next+
Whiteboard: [sg:high] needs new 1.8.1 patch → [sg:high]
Comment on attachment 378031 [details] [diff] [review] for 1.8 branch (attempt 2) Approved for 1.8.1.22, a=dveditz for release-drivers
Attachment #378031 - Flags: approval1.8.1.next+
new revision: 1.31.2.25; previous revision: 1.31.2.24
Keywords: fixed1.8.1.22
Verified for 1.8.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.22pre) Gecko/20090602 SeaMonkey/1.1.17pre using testcases.
Keywords: fixed1.8.1.22 → verified1.8.1.22
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: