Closed Bug 520522 Opened 15 years ago Closed 14 years ago

Bypassing XOW by using XPCNativeWrapper.wrappedJSObject

Categories

(Core :: XPConnect, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.2
Tracking Status
blocking2.0 --- beta1+
blocking1.9.2 --- needed
status1.9.2 --- wanted
blocking1.9.1 --- needed
status1.9.1 --- wanted

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

References

Details

(Whiteboard: [sg:high][3.6.x] critical with a privileged context to attack)

Attachments

(1 file)

The fix for bug 514435 can be circumvented.  By using XPCNativeWrapper, it's
possible to get a SJOW whose unsafe object is not a XOW.
Attached file testcase —
This tries to get cookies for www.mozilla.com.
I should have seen this coming :(.
Whiteboard: [sg:high] critical with a privileged context to attack
blocking1.9.1: --- → ?
blocking2.0: --- → ?
status1.9.1: --- → ?
Flags: wanted1.9.0.x?
Flags: blocking1.9.2?
Flags: blocking1.9.0.16?
blocking1.9.1: ? → .5+
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.2?
Flags: blocking1.9.0.16?
Flags: blocking1.9.0.16+
Flags: blocking1.9.2?
Assignee: nobody → mrbkap
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.2
Blake, any progress on a patch for this yet?
Workin' on it! bug 524994 is a prereq, though.
Depends on: 524994
Flags: blocking1.9.0.16+ → blocking1.9.0.17+
blocking1.9.1: .6+ → .7+
Unblocking on this per discussion with mrbkap and damons. Blake, keep this your top priority, and we'll consider a fix once it's ready, but we won't be holding the release for this.
Flags: blocking1.9.2+ → blocking1.9.2-
How is this one looking for 1.9.2.1/1.9.1.8/1.9.0.18 ? It's scary-close to the code-freeze for the latter two (and maybe 1.9.2.1) to be considering "Flatten out wrapper hierarchy" (prerequisite bug 524994).
Whiteboard: [sg:high] critical with a privileged context to attack → [sg:high][3.6.x] critical with a privileged context to attack
I have a patch for this. It's unfortunately conglomerated with some stuff that we can't land on old branches, but I'll work on teasing apart the requisite parts soon.
blocking1.9.1: .8+ → .9+
blocking1.9.2: --- → ?
Flags: blocking1.9.0.18+ → blocking1.9.0.19+
We should fix this for 1.9.3.
blocking2.0: ? → beta1
blocking1.9.2: ? → needed
Should this continue to block 1.9.0.19/1.9.1.9 or can it wait until a future release? Getting close to code freeze deadline.
blocking1.9.1: .9+ → needed
Flags: blocking1.9.0.19+ → blocking1.9.0.19-
Fixed by bug 533600.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
mrbkap: then should bug 533600 be back-ported to the affected branches?
Yes.
Are we ready to take the fix on the branches now?
blocking1.9.1: needed → .12+
blocking1.9.2: needed → .8+
Depends on: 533600
Talked to Blake, he is worried about this being taken on the branch at this time and doesn't expect to make code-freeze. I have got assurances he will make a special point to get it into the next release, so I am moving the blocking flag forward (one last time).
(err, I will do so once the flag values are created)
blocking1.9.1: .12+ → needed
blocking1.9.2: .9+ → needed
blocking1.9.1: needed → .13+
blocking1.9.2: needed → .10+
sg:high -> punt to next version.
blocking1.9.1: .14+ → needed
blocking1.9.2: .11+ → needed
(In reply to comment #16)
> I have got assurances he will make a special point to get it into
> the next release, so I am moving the blocking flag forward

Is now the time?
(In reply to comment #7)
> I have a patch for this. It's unfortunately conglomerated with some stuff
> that we can't land on old branches, but I'll work on teasing apart the
> requisite parts soon.

mrbkap: what ever happened to this patch?
The fix for this bug got subsumed into compartments.
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: