Closed
Bug 1006229
Opened 10 years ago
Closed 10 years ago
Assert that AudioBuffer::SetRawChannelContents cannot be called on AudioBuffer objects which might have a neutered buffer
Categories
(Core :: Web Audio, defect)
Tracking
()
RESOLVED
FIXED
mozilla32
Tracking | Status | |
---|---|---|
firefox32 | --- | fixed |
firefox-esr24 | --- | unaffected |
firefox-esr31 | --- | wontfix |
b2g-v2.0 | --- | fixed |
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
Details
(Keywords: sec-audit, Whiteboard: [adv-main32-])
Attachments
(1 file)
1.24 KB,
patch
|
padenot
:
review+
|
Details | Diff | Splinter Review |
AudioBuffer's typed arrays can be neutered in two ways: * C++ code calling AudioBuffer::GetThreadSharedChannelsForRate. * The object being handed off to JS. SetRawChannelContents is only safe if the typed arrays have not been neutered. I think the following in SetRawChannelContents will assert the summary of this bug: MOZ_ASSERT(!GetWrapperPreserveColor() && !mSharedChannels, "The AudioBuffer object should not have been handed to JS or have C++ callers neuter its typed array");
Updated•10 years ago
|
Attachment #8423141 -
Flags: review?(paul) → review+
Assignee | ||
Comment 2•10 years ago
|
||
Comment on attachment 8423141 [details] [diff] [review] Patch (v1) [Security approval request comment] How easily could an exploit be constructed based on the patch? This is just an assertion to prevent future security bugs. Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? This is just an assertion to prevent future security bugs. Which older supported branches are affected by this flaw? This only needs to land on trunk. If not all supported branches, which bug introduced the flaw? Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? How likely is this patch to cause regressions; how much testing does it need? A debug-only assertion, 0 risk.
Attachment #8423141 -
Flags: sec-approval?
Comment 3•10 years ago
|
||
Comment on attachment 8423141 [details] [diff] [review] Patch (v1) If this is a sec-audit rated issue, it doesn't need a sec-approval to go in.
Attachment #8423141 -
Flags: sec-approval?
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 4•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/9966d1b73aa5
Keywords: checkin-needed
Comment 5•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/9966d1b73aa5
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-b2g-v2.0:
--- → fixed
status-firefox32:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Updated•10 years ago
|
status-firefox-esr24:
--- → unaffected
Comment 6•10 years ago
|
||
Fix pertains to an audit without exploitable bug. If a test materializes or if you'd like QE to look at this, say the word. Marking qaverify- for now.
QA Whiteboard: qe-verify[-]
Updated•10 years ago
|
QA Whiteboard: qe-verify[-] → qe-verify-
Updated•10 years ago
|
Whiteboard: [adv-main32-]
Updated•10 years ago
|
QA Whiteboard: qe-verify-
Flags: qe-verify-
Updated•10 years ago
|
status-firefox-esr31:
--- → wontfix
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•8 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•