Closed Bug 1005578 Opened 5 years ago Closed 5 years ago

nsStandardURL::SetHost called net_ToLowerCase with a bogus pointer, #2

Categories

(Core :: Networking, defect, critical)

x86_64
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla32
Tracking Status
firefox29 --- wontfix
firefox30 --- verified
firefox31 --- verified
firefox32 + verified
firefox-esr24 --- unaffected
b2g18 --- wontfix
b2g-v1.1hd --- wontfix
b2g-v1.2 --- fixed
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed
seamonkey2.26 --- fixed

People

(Reporter: jruderman, Assigned: valentin)

References

(Blocks 1 open bug)

Details

(Keywords: crash, sec-critical, testcase, Whiteboard: [adv-main30+])

Crash Data

Attachments

(3 files)

Same symptoms as bug 991471, different testcase.
Attached file stack (ASan)
Crash Signature: [@ net_ToLowerCase(char*, unsigned int) ]
Ok, so the problem here is as follows:

var url = new URL("http://mozilla.org/"); // creates an nsStandardURL object

url.href = "javascript: 5";
// it first checks that ioService->NewURI(href,...) succeeds. It does.
// then it does aRv = mURI->SetSpec(href); This fails, as mURI is nsStandardURL, not a nsJSURI
// so all of the parameters in the nsStandardURL object get cleared

url.hostname = "allizom.org";
// tries to set the hostname, but the url is missing everything, including a scheme. From here we have a bad offset and crash.
Attached patch url_crash.patchSplinter Review
According to the spec, we should discard the old url object when calling url.href

http://url.spec.whatwg.org/#concept-uu-set-the-input
Assignee: nobody → valentin.gosu
Status: NEW → ASSIGNED
Attachment #8417035 - Flags: review?(bzbarsky)
Group: core-security
Whiteboard: crash, sec-critical, testcase
Comment on attachment 8417035 [details] [diff] [review]
url_crash.patch

Yeah, makes sense.
Attachment #8417035 - Flags: review?(bzbarsky) → review+
Comment on attachment 8417035 [details] [diff] [review]
url_crash.patch

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
The changes made in the patch don't immediately reveal the vulnerability. It would be very difficult to create an exploit based on this patch.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
The comment does say what the problem is, and it might need to be changed.

Which older supported branches are affected by this flaw?
All branches are affected.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
It should be easy to apply this patch on all branches.


How likely is this patch to cause regressions; how much testing does it need?
Attachment #8417035 - Flags: sec-approval?
(In reply to Valentin Gosu [:valentin] from comment #5)
> How likely is this patch to cause regressions; how much testing does it need?
Unlikely. Not a risky change, and it is the specified behavior in the spec.
Comment on attachment 8417035 [details] [diff] [review]
url_crash.patch

sec-approval+ for trunk.

Please create Aurora, Beta, and ESR24 patches and nominate them once it is in trunk.
Attachment #8417035 - Flags: sec-approval? → sec-approval+
https://hg.mozilla.org/integration/mozilla-inbound/rev/2ffa88afe433

Please request Aurora/Beta/ESR24 approval on this ASAP to expedite it being uplifted everywhere else it needs to go.
It seems I misread the output of hg log, and that the error was actually introduced by http://hg.mozilla.org/mozilla-central/rev/f2199d73aef6
ESR24 is not affected.
Comment on attachment 8417035 [details] [diff] [review]
url_crash.patch

[Approval Request Comment]
Issue caused by (bug #): Bug 887364
User impact if declined: Security concerns
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none
Attachment #8417035 - Flags: approval-mozilla-beta?
Attachment #8417035 - Flags: approval-mozilla-aurora?
Comment on attachment 8417035 [details] [diff] [review]
url_crash.patch

Valentin, don't hesitate to be a bit more verbose next time ;)
Attachment #8417035 - Flags: approval-mozilla-beta?
Attachment #8417035 - Flags: approval-mozilla-beta+
Attachment #8417035 - Flags: approval-mozilla-aurora?
Attachment #8417035 - Flags: approval-mozilla-aurora+
(In reply to Sylvestre Ledru [:sylvestre] from comment #11)
> Valentin, don't hesitate to be a bit more verbose next time ;)
Thanks! I will :)
https://hg.mozilla.org/mozilla-central/rev/2ffa88afe433
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Whiteboard: [adv-main30+]
Confirmed crash on 2014-04-21, debug build of Fx30.
Verified fixed 2014-06-03, ASan builds of Fx30, Fx31 and Fx32.
Applied ontop of a relbranch for SeaMonkey 2.26.1 (Gecko 29 based):

https://hg.mozilla.org/releases/mozilla-release/rev/908f619b9122
Group: core-security
You need to log in before you can comment on or make changes to this bug.