1311869 - Denial of Service Vulnerability. High CPU. Hang or Crash. [@ IPCError-browser | ShutDownKill ]

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[Soufiane Boussali]

Attachment: Capture d’écran 2016-10-21 à 00.04.16.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20161019084923

Steps to reproduce:

Hello BugZilla,
Attackers can actually exploit Remotely this vulnerability with hosting a simple code HTML and send it to any victim around any network

POC Remote Exploitation : http://exemple-noip.com/0Daymozilla.html


POC LOCAL Steps to Reproduce:
1 - open Safari 
2 - copy & past this post exploitation JS in browser URL  and click enter

data:text/html,<script>location+=location+'A'.repeat(100000000);</script>

3 - Denial Of Service Attack Done



Tested On macbookpro retina 2015 
Version: macOS Sierra 10.12
 


Actual results:

Expected Results: CPU status = 100% 

FireFox Completely Crashed 


Expected results:

should verify buffer and bypass it without any crash

Comment 1

[Benjamin Smedberg]

We don't keep local DoS bugs private.

Comment 2

[Adrian Florinescu [:aflorinescu]]

I tested this issue on Windows, Linux and Mac OS. 

Here are the results:

1. Ubuntu 16.04 x664 Version 52.0a1 Build ID 20161025030205

FF52 doesn't crash but starts consuming memory as expected, processor raises to 25-30% then drops back to normal parameters.
Chrome crashes and kills the page

2. Windows 7 x64 Version  52.0a1 Build ID  20161024030205

FF52 doesn't crash, the processor raises to 15% then drop down to normal parameters.
Chrome has the same behavior like on Ubuntu, crashes and kills the page.

3. Mac OS X 10.12 Version52.0a1   Build ID 20161025030205

FF52 doesn't crash, the processor raises to 170% for ~2 seconds and then drops down to normal parameters.
Safari crashes.
Chrome, (Google Chrome Helper) processor raises to ~110 and after 5 minute crashes and kills the page.

Note: Firefox release 49.0.2 has the same behavior like Nightly. The only significant increase of CPU was on MAC OS.


Based on the above, I don't think this reported crash is a Firefox issue, but a Safari one. Based on this, I'm inclined to set this bug as invalid. 


(In reply to Soufiane Boussali from comment #0)
> Actual results:
> 
> Expected Results: CPU status = 100% 
> 
> FireFox Completely Crashed 

Soufiane, if Firefox crashed, could you please submit a crash report?

Comment 3

[Soufiane Boussali]

Attachment: Firefox-Crash.txt

Comment 4

[Soufiane Boussali]

Attachment: 20161025_162713.jpg

Comment 5

[Soufiane Boussali]

Attachment: 20161025_163042.jpg

Comment 6

[Soufiane Boussali]

Excuse me for this trouble in name of product, iv'e report this crash for safari at bugreport.apple.com, 
But this issue it's for firefox product an here bellow the report of crash :



Thanks To see the Full report Crash & screenshots in Attachment

Comment 7

[Adrian Florinescu [:aflorinescu]]

That helps a bit, but we'd prefer if you could open the FF browser, type in address bar about:crashes and given the fact that you submitted the crash report, copy paste that link here.

Comment 8

[Soufiane Boussali]

https://crash-stats.mozilla.com/report/index/c925358a-45e5-46ba-adf0-917192161026

Comment 9

[Adrian Florinescu [:aflorinescu]]

Daniel, could you please take a look at this bug? I'm also under the impression that there is a dupe for this already logged, but I can't seem to find it.

Comment 10

[Daniel Veditz [:dveditz]]

(In reply to Soufiane Boussali from comment #0)
> POC Remote Exploitation : http://exemple-noip.com/0Daymozilla.html

No such server. At least not visible from California anyway.

> Tested On macbookpro retina 2015 
> Version: macOS Sierra 10.12

Adrian: what processor do you have? I got the same results you did on a mid-2014 Macbook Pro retina. I've got an intel CPU and according to the crash in comment 8 the reporter has an amd64 chip. Seems unlikely to be the difference. I've got twice the memory she does; that seems more likely to be relevant.

She's crashing deep in Apple code. I wonder if Apple just can't handle drawing strings that long without enough memory? 100 Million shouldn't be approaching the limit on strings. Then again I'm not sure how a 100 Million character string requires Gigabytes of memory to process.


(In reply to Adrian Florinescu [:AdrianSV] from comment #9)
> I'm also under the impression that there is a dupe for this already logged,
> but I can't seem to find it.

The one we see a lot is a loop doubling strings, and usually it dies on OOM long before it gets around to trying to draw it. This one crashed the reporter apparently while drawing (unless the stack is corrupt, which is possible). I don't think I've seen this one specifically.

Comment 11

[Soufiane Boussali]

(In replay from comment #0)
 
> POC Remote Exploitation : http://exemple-noip.com/0Daymozilla.html

This script isn't hosted, it's just a demonstration who attackers can use to exploit it remotely thats why I've maked a public @IP.

Comment 12

[Adrian Florinescu [:aflorinescu]]

(In reply to Daniel Veditz [:dveditz] from comment #10)
> Adrian: what processor do you have? I got the same results you did on a
> mid-2014 Macbook Pro retina. I've got an intel CPU and according to the
> crash in comment 8 the reporter has an amd64 chip. Seems unlikely to be the
> difference. I've got twice the memory she does; that seems more likely to be
> relevant.

Daniel, according to the crash report, seems to me that Soufiane has a Intel CPU as well (one of these two): 
Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz [Family 6 Model 61 Stepping 4]
Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz [Family 6 Model 61 Stepping 4]


Soufiane, could you perhaps confirm your CPU?

Comment 13

[Adrian Florinescu [:aflorinescu]]

I forgot to actually answer the question:my CPU is an I5, and this is what i get in crash reporter from it: ( Build Architecture amd64 ; Build Architecture Info family 6 model 70 stepping 1 | 4 ). I wonder if this is by design?

Also, the test machine I've got the results in comment 2 is an IMAC, since I haven't had a macbook at disposal at that time. Let's see if on a model that's closer to Soufiane's configuration we get the same behavior as in both our cases. I think this bug might also be related to hardware configuration.

Ciprian, could test and post back the results and your configuration? With some luck, the crash report as well.

Comment 14

[Soufiane Boussali]

(In reply to Adrian Florinescu [:AdrianSV] from comment #12)

> Soufiane, could you perhaps confirm your CPU?

Of course @Adrian here all information about Hardware configuration:

Laptop : Macbookpro 13 Retina 2015 
CPU : i5-5257U 2.7 GHZ - Turbo boost 3.1 GHZ 
Graphic : Intel Iris 6100
RAM : 8GB LPDDR 1866 MHZ
Storage : 256GB SSD

Comment 15

[Ciprian Muresan [:cmuresan], Ecosystem QA]

I tested the issue on a Macbook Pro 13" Early 2015
CPU : i5 2.7 GHZ
Graphics : Intel Iris 6100
RAM : 8GB DDR3 1867 MHZ
both on 10.11 and 10.12

Firefox 49.0.2 hangs indefinitely on both OS's and I managed to get a crash on 10.11 (https://crash-stats.mozilla.com/report/index/91f96a15-875a-4425-8c7a-042902161031)

Nightly 52.0a1 does not crash at first, CPU usage spikes for a while (100-200%) and after a bit the browser becomes responsive again. However if the browser is restarted a new crash can be found in about:crashes with the same signature as the reporters.


STR:
1. Open the browser with a new profile.
2. Write "data:text/html,<script>location+=location+'A'.repeat(100000000);</script>" in the URL bar and press Enter.
3. Wait for the browser to become responsive and open a new tab.
4. Restart the browser with the same profile. (easiest way is to restart with the Developer Toolbar)

Actual results:
The browser hangs for a while and a new crash report appears in about:crashes.

https://crash-stats.mozilla.com/report/index/89d0efa6-a864-4bf1-aebb-21bf42161031

Comment 16

[Soufiane Boussali]

(In reply to Ciprian Muresan [:cmuresan] from comment #15) 

your comment duplicate because you just copy past my report 

I've mentioned all this informations if you reading the firsts comments

Special credit to : Othmane Tamagart

Comment 17

[Adrian Florinescu [:aflorinescu]]

(In reply to Soufiane Boussali from comment #16)
> (In reply to Ciprian Muresan [:cmuresan] from comment #15) 
> 
> your comment duplicate because you just copy past my report 
> 
> I've mentioned all this informations if you reading the firsts comments
> 
> Special credit to : Othmane Tamagart

Soufiane, Ciprian is a colleague of mine whom I asked to see if he can reproduce the exact result you provided on his machine, which is almost identical to yours. His comment is not a duplicate, but a confirmation that the issue and the crash that neither Daniel or I could reproduce exactly as you described is not happening only your machine alone.     
Ciprian's work is actually a step forward, following it we'll see what Daniel has to say on this info, assign a component and possibly involve more developers to get this problem prioritized and fixed.

Comment 18

[Daniel Veditz [:dveditz]]

(In reply to Ciprian Muresan [:cmuresan] from comment #15)
> Firefox 49.0.2 hangs indefinitely on both OS's and I managed to get a crash on 10.11
> (https://crash-stats.mozilla.com/report/index/91f96a15-875a-4425-8c7a-042902161031)

That's a more interesting/disturbing crash than the one in comment 8. Crashes on Mac don't tell us if the access violation was reading or writing, but either way you don't want to see that in a memcpy() call. It's just after an assert about an out-of-bounds situation so it'd be interesting to try this in a debug build. 

Also worth trying with a 32-bit Firefox Windows build -- it would hit memory limits sooner.

> However if the browser is restarted a new crash can be found in about:crashes with the
> same signature as the reporters.

Crashing at ShutDownKill usually means the browser is exiting and it's killing off a hung/un-responsive child process. The stacks themselves are totally different, but that just means it got killed at a different spot. Your crash looks like it was actually hung (the "active" thread was waiting); Soufiane's ShutDownKill was busy doing something down in CoreGraphics (MacOS drawing APIs).

Comment 19

[Daniel Veditz [:dveditz]]

Probably also relevant that Soufaine has e10s disabled ("E10SCohort: disqualified-test") while Ciprian is using e10s (the "test" cohort).

Comment 20

[Soufiane Boussali]

(In reply to Daniel Veditz [:dveditz] from comment #19)
> Probably also relevant that Soufaine has e10s disabled ("E10SCohort:
> disqualified-test") while Ciprian is using e10s (the "test" cohort).

Actually we have the same version of CPU = amd64

my Denial of service test in OS X 10.12 cited in report crash bellow :

> https://crash-stats.mozilla.com/report/index/c925358a-45e5-46ba-adf0-917192161026

But @Ciprian has tested this dos in OS X 12.11 like his report crash bellow :

> https://crash-stats.mozilla.com/report/index/89d0efa6-a864-4bf1-aebb-21bf42161031

I think somthing is wrong on the api that's could verifying buffer before execution

Comment 21

[Adrian Florinescu [:aflorinescu]]

(In reply to Daniel Veditz [:dveditz] from comment #19)
> Probably also relevant that Soufaine has e10s disabled ("E10SCohort:
> disqualified-test") while Ciprian is using e10s (the "test" cohort).

Got a bit of lag with work week and PTO, sorry about that.
I believe you are right and that is the main difference, Soufiane had e10s dissabled, while Cipri had e10s enabled. But given the fact that a new version is up, I'd like to ask Soufiane to invest a few minutes to see if this bug can be reproduced on the latest version: 50.1, maybe we get some additional information from the crash-report.

Other than the above, I'm out of ideas, so probably next step should be assigning it to the right component (probably core::dom would make sense) and move forward from there.

Comment 22

[Othmane T.]

Hi Adrian, 

First of all thank you for the re-check, I am the author of the vulnerability that's why soufian added me to the report, I have just checked the latest version 50.1 on Windows and Linux invironments

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.