829719 - DoS Bufferoverflow (long data: URL)

Status: NEW

(Core :: General, defect)

Description

[Conrad Kirschner]

Attachment: PoC.php

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

Steps to reproduce:

By downloading an file with a large type name via an data-URI
Here you can see the source code. 
http://pastebin.com/QV4fNqKJ




Actual results:

Firefox crashed or if it is not flow the memory over 1 GB the file-type is not readable because its overrides by self. (With minimize the lenght of the filetype Firefox use a lot of Memory crashed but not exit the prozess and slow the pc a lot!)


Expected results:

Firefox should show the Dowload and not crashed it, also the file-type in 2 rows or short it. 


[I didn't checked it for executable Memory, so I choose to hide it.]

Comment 1

[Conrad Kirschner]

I saw that I can choose an -> MIME Type: here for the file I uploaded.

Maybe if you feed it with this exploit, your browser will be crashed. I didn't checked it.

Comment 2

[Conrad Kirschner]

[It is maybe not a real bug, but I nerved a lot from these failure...]

var string = '<iframe src="mailto:[e-mail]"></iframe>';
while(true){
document.write(string);
}

[What's happen -> Firefox crashes...]
Often this endless loop is an programm misstake, but say game over isn't the right way to show these problem.

Comment 3

[Daniel Veditz [:dveditz]]

let's leave comment 2 to another bug (in fact I'm sure we have the mailto: issue on file already).

(In reply to Conrad Kirschner from comment #0)
> By downloading an file with a large type name via an data-URI
> Here you can see the source code. 
> http://pastebin.com/QV4fNqKJ

I can't actually see that pastebin, it's marked private. Is it the same as what you attached to the bug?

Comment 4

[Conrad Kirschner]

Yes, It is the same ... I couldn't Edit it anymore ... 

*I think you have it already. So I haven't to open a new bug file.

Comment 5

[Matt Wobensmith [:mwobensmith][:matt:]]

In deploying this PHP file, I see errors, which I'm not able to fix immediately.

Can you deploy this PHP file on a web server and give us the URL? That would help. Thank you.

Comment 6

[Conrad Kirschner]

This creates just an large string, save the string in an file and read it out, the readed string is the output. 


I have downloaded this for you as an html file. Each download window generates arround 200 MB RAM and is blocking while creating. This has the fact that no windows can closed and firefox will crash on 1,3 GB ram. 

I upload you this on Xup.in
http://www.xup.in/dl,17304044/PoC.php.htm/

(FOR A DELETE change xx to tt: hxxp://www.xup.in/dl,17304044/PoC.php.htm/ )

or here -> 
ck111.lima-city.de/PoC.php.html

Filesize 4 MB. 

Worked also in Google Chrome [Just killing the Process.]

[Faster Downloading could be preformed by ajax, but thats not necessary for an PoC, because I don't want to make stress for user.]

Comment 7

[Conrad Kirschner]

[Lima City link doesn't work, maybe too slow.]

(And I don't want to put it on my homeserver, sry) 

I hope you get downloaded the file from xup.in, I have added an Timer after 7000 mil. secounds it starts, before that everything is possible ...
[For Google Chrome user it could used for blocking an attack, if someone try Chrome will kicked off :D In Firefox the same]

Comment 8

[Matt Wobensmith [:mwobensmith][:matt:]]

Thank you very much for the modified file. I wish I had thought of that solution myself. 

I've run this on today's build of mozilla-central on Win (debug) and Mac/Linux (ASan) and while it is very slow, it does not crash. It eventually stabilizes.

So, I can't reproduce a crash. If you can, is it possible for you to generate a crash log for us?

Comment 9

[Conrad Kirschner]

I think that you have an more powerfull computer. Try to make the string longer (8 MB) then you will have the same result.


[[01/19/13 12:01:03] Crash report submission failed: Es konnte keine Verbindung mit dem Revokationsserver hergestellt werden, oder es konnte keine definitive Antwort abgerufen werden.] [Could not conect with Server or could not read the answer]

I uploaded on xup.in

http://www.xup.in/dl,59854106/logs.rar/

In study the bug I saw that firefox crashed everytimes on 1,3 GB. Can it be possible that Firefox check that he doesn't use more than 34% of the RAM? That could explain why your firefox doesn't crash.

Comment 10

[Conrad Kirschner]

Add: Testet on diffrend Win32 versions, works always with max RAM 4(3,5 GB)

Comment 11

[Matt Wobensmith [:mwobensmith][:matt:]]

I tried a few different Windows configs, and was able to get one (Win7 64) to crash consistently. I altered your test to increase the length of the string, but it worked. 

https://crash-stats.mozilla.com/report/index/c6802dc6-e64e-4b6e-a98e-611692130124

Sadly, I can't get it to crash on Mac/Linux, where I have better memory debugging tools, but this is a start.

Comment 12

[Conrad Kirschner]

wann wird es gepatcht sein? 
Bounty wirds ned geben oder?

Comment 13

[Conrad Kirschner]

[sry. in english:]

When will it be patched?
and I will not get an bounty, will i?