893036 - Robohornet benchmark crashes Firefox release (stack overflow)

Status: RESOLVED DUPLICATE of bug 485941

(Core :: CSS Parsing and Computation, defect)

Description

[Mark Straver]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

I went to robohornet.org and tried to run the test. Upon running the test, robohornet would crash Firefox on step 3: descendant selectors.

According to the site, this step tests descendant selectors at different DOM depths (up to 1000 levels deep).
This could possibly be exploitable, it seems to be some sort of out of bounds crash.

System is Windows 7 SP1 x64, on AMD Phenom II processor with plenty of free ram.
Someone else confirmed this crash on an I5-2320 w/ 32gb ram, Win 7 x64 SP-1.



Actual results:

Firefox crashed, crashreports have been submitted.


Expected results:

Firefox should be able to complete the test.

Comment 1

[Mark Straver]

Details:
Crash ID: f06b7eca-969d-4b96-891c-211502130712
Signature: SelectorMatches in layout/style/nsCSSRuleProcessor.cpp
Crash Reason 	EXCEPTION_STACK_OVERFLOW
Crash Address 	0x5d4408d3

Comment 2

[Mark Straver]

Added another crash sig verified by a colleague on an Intel machine.

Comment 3

[Andrew McCreight [:mccr8]]

Stack overflows usually aren't security issues.

Comment 4

[Mark Straver]

(In reply to Andrew McCreight [:mccr8] from comment #3)
> Stack overflows usually aren't security issues.

They aren't?
If I'm not mistaken, any specifically triggered buffer overflow can lead to arbitrary code execution. I'd say that would make this a security issue; not sure about the severity of it, of course.

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Crash reports are:
bp-f06b7eca-969d-4b96-891c-211502130712
bp-7da22c06-9db4-43ac-817c-99b5c2130712

Stack overflow (stack exhaustion) != stack buffer overflow.

Comment 7

[Mark Straver]

Sorry if somewhere along the line, terminology got muddled then. I was always taught that a "stack overflow" is a "type of buffer overflow where the buffer is the stack". OWASP seems to agree with that definition.
https://www.owasp.org/index.php/Stack_overflow

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Wikipedia and the Windows API do not:
http://en.wikipedia.org/wiki/Stack_overflow
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363082%28v=vs.85%29.aspx

Comment 9

[Andrew McCreight [:mccr8]]

What is failing here is the allocation of the stack frame due to a deep stack.  Generally that's not a huge deal.  What the OWASP thing seems to be talking about is writing off the end of a data structure allocated on the stack.

Comment 10

[Mark Straver]

@David: Not to nitpick, but I'd like to point out that Wikipedia at least *does* agree (I haven't checked the MS article): "When a program attempts to use more space than is available on the call stack (that is, when it attempts to access memory beyond the call stack's bounds, *which is essentially a buffer overflow*), the stack is said to overflow, typically resulting in a program crash" -- That is what is happening. So basically wikipedia is also calling a stack overflow essentially a buffer overflow where the buffer is the stack. Both articles on wikipedia (stack overflow/stack buffer overflow) are saying pretty much the same thing although one focuses more on the exploit side of things, while the other provides a more generic description. I'll do some more reading when I have the opportunity about the intricate differences between the two terms.

@Andrew: As said, I wasn't sure about the severity ;) It seems to not be something severe in this particular case (I'll leave the code evaluation up to you guys), but it caused a red-flag response for me seeing an app crash and a stack overflow message in combination, hence my bug report was initially marked for security.