Bug 436741 (CVE-2008-5014)

"Assertion failure: OBJ_IS_NATIVE(obj)" with __proto__ mangling

VERIFIED FIXED

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Assigned: mrbkap)

Tracking

(Blocks: 1 bug, 5 keywords)

Trunk
assertion, hang, testcase, verified1.8.1.18, verified1.9.0.2
Points:
---
Bug Flags:
wanted1.9.0.x +
blocking1.8.1.18 +
wanted1.8.1.x +
in-testsuite +
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical?])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
Created attachment 323256 [details]
testcase (crashes or hangs Firefox when loaded)

Loading the testcase kills Firefox.

Debug:
Assertion failure: OBJ_IS_NATIVE(obj), at /Users/jruderman/central/mozilla/js/src/jslock.cpp:1187

Opt:
Hang.

Security-sensitive for now because I don't know whether this is a memory safety bug in opt builds.
(Reporter)

Comment 1

9 years ago
Created attachment 323257 [details]
stack trace
Assignee: general → nobody
Component: JavaScript Engine → XPConnect
OS: Mac OS X → All
QA Contact: general → xpconnect
Hardware: PC → All
Blake, can you take this one?

/be
mrbkap's out for a couple, few more weeks still, isn't he?
(Assignee)

Updated

9 years ago
Assignee: nobody → general
Component: XPConnect → JavaScript Engine
QA Contact: xpconnect → general
(Assignee)

Comment 4

9 years ago
Created attachment 326322 [details] [diff] [review]
Guess

This seems like an ancient bug dating back to bug 72354 (2001!). The code currently always locks obj2 when it is returned from a newresolve hook. Furthermore, when it finds out that obj2 is not native, it unlocks it. But both js_LockObj and js_UnlockObj (called directly via JS_{UN,}LOCK_OBJ) assert that the given object is native!

The fix proposed here is to not try to lock (or unlock) a non-native object. Note that in this case, the non-native object is a shavarray, but could just as easily be a liveconnect object.
Assignee: general → mrbkap
Status: NEW → ASSIGNED
Attachment #326322 - Flags: review?(brendan)
Comment on attachment 326322 [details] [diff] [review]
Guess

Yeah, this makes sense. Although for liveconnect do we have thread safety issues? For shavarrays my hope is to convert 'em to sparse upon crossing a thread boundary.

/be
Attachment #326322 - Flags: review?(brendan)
Attachment #326322 - Flags: review+
Attachment #326322 - Flags: approval1.9.0.1?
(Assignee)

Comment 6

9 years ago
Created attachment 326444 [details] [diff] [review]
Better

Looking further down the loop shows that if the non-native object fails to resolve the id, we'll try to unlock the non-native obj2.
Attachment #326322 - Attachment is obsolete: true
Attachment #326444 - Flags: review?(brendan)
Attachment #326322 - Flags: approval1.9.0.1?
Comment on attachment 326444 [details] [diff] [review]
Better

Glad someone's looking!

/be
Attachment #326444 - Flags: review?(brendan) → review+
(Assignee)

Comment 8

9 years ago
Fix pushed as changeset 8eac0738eaab.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 9

9 years ago
Want for branch blake?
Flags: wanted1.9.0.x?
(Assignee)

Comment 10

9 years ago
Comment on attachment 326444 [details] [diff] [review]
Better

Yeah. I think this is necessary for the array prototype functions getting "this" wrong bug.
Attachment #326444 - Flags: approval1.9.0.1?
Attachment #326444 - Flags: approval1.9.0.1? → approval1.9.0.2?
Comment on attachment 326444 [details] [diff] [review]
Better

Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #326444 - Flags: approval1.9.0.2? → approval1.9.0.2+

Comment 12

9 years ago
Created attachment 332904 [details]
js1_5/extensions/regress-436741.js

Updated

9 years ago
Flags: in-testsuite+
Flags: in-litmus-
(Assignee)

Comment 13

9 years ago
Fix checked into the 1.9 branch.
Keywords: fixed1.9.0.2

Comment 14

9 years ago
verified fixed 1.9.0/trunk linux/mac/win.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.2 → verified1.9.0.2
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.18+
Whiteboard: [sg:critical?] not fixed on 1.8 yet, hold advisory.
(Assignee)

Comment 15

9 years ago
Comment on attachment 326444 [details] [diff] [review]
Better

This applies cleanly to the 1.8 branch.
Attachment #326444 - Flags: approval1.8.1.18?
Comment on attachment 326444 [details] [diff] [review]
Better

Approved for 1.8.1.18, a=dveditz for release-drivers
Attachment #326444 - Flags: approval1.8.1.18? → approval1.8.1.18+
(Assignee)

Comment 17

9 years ago
Fixed on the 1.8 branch too (although it isn't showing up in bonsai, probably because I hit ctl+c in the middle of checking in).
Keywords: fixed1.8.1.18

Comment 18

9 years ago
v 1.8.1.18
Keywords: fixed1.8.1.18 → verified1.8.1.18

Updated

9 years ago
Attachment #326444 - Flags: approval1.8.0.15+

Comment 19

9 years ago
Comment on attachment 326444 [details] [diff] [review]
Better

a=asac for 1.8.0
Alias: CVE-2008-5014
Group: core-security

Comment 20

9 years ago
test landed http://hg.mozilla.org/mozilla-central/rev/dcddc30c2960 and cvs
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Whiteboard: [sg:critical?] not fixed on 1.8 yet, hold advisory. → [sg:critical?]
You need to log in before you can comment on or make changes to this bug.