Closed Bug 1040575 Opened 10 years ago Closed 10 years ago

copy SVGSVGElement.currentTranslate if we insert it into an SVGPointList

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla34
Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
firefox34 --- fixed
firefox-esr24 --- unaffected
firefox-esr31 --- fixed
b2g-v1.3 --- unaffected
b2g-v1.3T --- unaffected
b2g-v1.4 --- unaffected
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: heycam, Assigned: heycam)

Details

(Keywords: sec-other, Whiteboard: [adv-main32-][adv-esr32-] hidden while bug 1018524 is)

Attachments

(2 files)

Attached patch patchSplinter Review
While looking at bug 1018524 I noticed that we also don't make a copy of SVGSVGElement.currentTranslate, an SVGPoint, if we try to insert it into a list.  I don't think this results in anything harmful (we don't have a tearoff table for SVGPoints) other than an odd coupling of currentTranslate and say a <polyline points=""> attribute, but I'm hiding this bug while bug 1018524 is still hidden.

I've changed Clone to Copy, to match the naming on SVGLengthList, and changed it to always return an SVGDOMPoint as it looks like the return-the-same-concrete-class behaviour isn't being relied upon.
Attachment #8458436 - Flags: review?(longsonr)
Attachment #8458436 - Flags: review?(longsonr) → review+
Attached patch testSplinter Review
Meant to include this test too.
Attachment #8459098 - Flags: review?(longsonr)
Attachment #8459098 - Flags: review?(longsonr) → review+
Keywords: sec-other
Whiteboard: hidden while bug 1018524 is
Landed at longsonr's request in bug 1018524. Should we backport this to the release branches as well or is it OK landing on trunk only?

https://hg.mozilla.org/integration/mozilla-inbound/rev/b4d871044fe8
Flags: needinfo?(longsonr)
Flags: in-testsuite+
It wants landing everywhere we land bug 1018524 it's potentially a similar hole although we've no known exploit so if you know about one (and everyone does now) you just might be able to use that knowledge here.
Flags: needinfo?(longsonr)
Comment on attachment 8458436 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: bug 886416 (31+)
[User impact if declined]: see comment 3
[Describe test coverage new/current, TBPL]: includes a test
[Risks and why]: low
[String/UUID change made/needed]: none
Attachment #8458436 - Flags: approval-mozilla-esr31?
Attachment #8458436 - Flags: approval-mozilla-beta?
Attachment #8458436 - Flags: approval-mozilla-aurora?
Given that this is rated sec-other, let's let this land on m-c before uplift.
https://hg.mozilla.org/mozilla-central/rev/b4d871044fe8
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Attachment #8458436 - Flags: approval-mozilla-esr31?
Attachment #8458436 - Flags: approval-mozilla-esr31+
Attachment #8458436 - Flags: approval-mozilla-beta?
Attachment #8458436 - Flags: approval-mozilla-beta+
Attachment #8458436 - Flags: approval-mozilla-aurora?
Attachment #8458436 - Flags: approval-mozilla-aurora+
There's no poc code or an exploitable bug that can be used for testing and verification. If there's something QE can do to test/verify this issue, please let us know and needinfo! Marking this as qe-verify- for the time being. (also as per comment #3, we currently don't have a known exploit)
Flags: qe-verify-
Whiteboard: hidden while bug 1018524 is → [adv-main32-][adv-esr32-] hidden while bug 1018524 is
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

Created:
Updated:
Size: