Status

()

Toolkit
View Source
6 years ago
6 months ago

People

(Reporter: chipik2, Unassigned)

Tracking

({sec-low})

15 Branch
x86
Windows 7
sec-low
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: stack-overflow DOS)

Attachments

(1 attachment, 1 obsolete attachment)

288 bytes, text/plain
Details
(Reporter)

Description

6 years ago
Created attachment 658103 [details]
POC.

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1

Steps to reproduce:

Click on the malformed link


Actual results:

When firefox trying to go on something like: view-source:view-source:view-source:view-source:view-source:...etc, he have a crash. 


Expected results:

Get error page or something like that
Component: Untriaged → View Source
Product: Firefox → Toolkit
Attachment #658103 - Attachment mime type: text/plain → text/html
Comment on attachment 658103 [details]
POC.

This testcase seems to be broken -- there's no 'tt' element so you don't add the string you built up.

Have you submitted any crashes? if you could paste some of the crash ID's you get ("bp-xxxxx" etc) from about:crashes that would help.
Attachment #658103 - Attachment is obsolete: true
(Reporter)

Comment 2

6 years ago
Created attachment 658581 [details]
POC_2
This is a little weird. We crash in nsACString_internal::Assign, doing a arena_malloc_large. The actual crash is with a EXCEPTION_STACK_OVERFLOW, but I don't see the usual sort of super huge repeating stack you normally see those kinds of things.  Maybe bsmedberg or jlebar have a better idea of what is going on in this string code.

The problem may just be the creation of a large string is causing an OOM crash, though I'd expect a moz_alloc_abort instead of a stack overflow. The crash shows 99% of system memory is used. I tried out the test case in a local debug build on OSX and it didn't seem to do anything in particular.
Oh, I spoke too soon. After letting it sit there for a bit, I tried to close the browser and ended up with a crash.

On OSX, the stack looks like:

arena_avail_tree_remove + 137 (jemalloc.c:3146)
arena_run_split + 619 (jemalloc.c:3333)
arena_run_alloc + 652 (jemalloc.c:3551)
arena_malloc_large + 101 (jemalloc.c:4161)
arena_malloc + 769 (jemalloc.c:4197)
imalloc + 235 (jemalloc.c:4207)
je_malloc + 135 (jemalloc.c:6291)
zone_malloc + 25 (jemalloc.c:6909)
malloc_zone_malloc + 82
malloc + 44
moz_malloc + 21 (mozalloc.cpp:67)
nsStringBuffer::Alloc(unsigned long) + 183 (nsSubstring.cpp:177)
nsACString_internal::MutatePrep(unsigned int, char**, unsigned int*) + 576 (nsTSubstring.cpp:130)
nsACString_internal::ReplacePrepInternal(unsigned int, unsigned int, unsigned int, unsigned int) + 58 (nsTSubstring.cpp:166)
nsACString_internal::ReplacePrep(unsigned int, unsigned int, unsigned int) + 171 (nsTSubstring.h:719)
nsACString_internal::Assign(char const*, unsigned int, mozilla::fallible_t const&) + 215 (nsTSubstring.cpp:311)
nsACString_internal::Assign(nsACString_internal const&, mozilla::fallible_t const&) + 328 (nsTSubstring.cpp:386)
nsACString_internal::Assign(nsACString_internal const&) + 33 (nsTSubstring.cpp:347)
nsCAutoString::nsCAutoString(nsACString_internal const&) + 70 (nsTString.h:468)
nsCAutoString::nsCAutoString(nsACString_internal const&) + 29 (nsTString.h:468)
nsDefaultURIFixup::CreateFixupURI(nsACString_internal const&, unsigned int, nsIURI**) + 253 (nsDefaultURIFixup.cpp:122)

...then about 500 more frames of nsDefaultURIFixup::CreateFixupURI. So I guess that's where the stack overflow is coming from.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

6 years ago
This looks like a non-exploitable DOS: stack exhaustion crashes aren't exploitable in general, and I think we should open this up.
Keywords: sec-low
Whiteboard: stack-overflow DOS
Group: core-security
You need to log in before you can comment on or make changes to this bug.