83.61 KB, text/plain
41.20 KB, image/jpeg
100 bytes, text/html
855 bytes, patch
|Details | Diff | Splinter Review|
791 bytes, patch
|Details | Diff | Splinter Review|
901 bytes, patch
|Details | Diff | Splinter Review|
374 bytes, text/html
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Yes, this isn't really a firefox bug. The page tries to display an image with height="9999999" width="9999999" -- this blue-screens windows. Reproducible: Always Steps to Reproduce:
I filed this because firefox should probably filter really huge images like this, especially if they can be used to exploit OS-level bugs.
The page appears to be gone or there's a typo in http://www.livejournal.com/community/roflcl/404836.html. Do you have a copy of the page source and image? We do filter out images ~64k on a side to prevent math overflows, but images anywhere near that large would likely exhaust a machine's memory. We should handle the OS telling us there's no more memory, but it appears the OS itself can't handle it. Specifying height and width as 9999999 in the <img> tag for smaller images affects layout, but doesn't cause problems when I test it. Unless you can find this page so we can test to see what it really is I'm going to assume this is the memory issue described in bug 214146 (don't be fooled by the png-specific summary) *** This bug has been marked as a duplicate of 214146 ***
The crash code is in http://jameth.whatthefuck.com/apr2005/11/deeplolz.txt. This is Windows-specific. The duplicate bug appears to be a Linux bug.
This now has been posted to Bugtraq.
Thanks. I didn't crash with that one, either, but some of the included images are already 404's -- I guess those might have been the big ones? It does chew up a lot of memory though, could kill a box with less. Clearing confidential flag, no point if this is on Bugtraq. We'll just get dupes.
Note updated URL. Not sure how long it'll last, since the previous incarnation got killed.
Created attachment 180605 [details] WARNING!! BLUE SCREEN!! testcase Captured the latest page. This does not run up memory or CPU usage (my initial guess), the blue screen message says something about a driver error. adding with the wrong MIME type intentionally to protect people
(I note that any poor IE users will still get bluescreened by text/plain.) Something causes the video driver to go into a long-running routine, eventually triggering a watchdog timer in the kernel.
the test image that was in the bug is now gone ;/ can someone find another version that breaks?
Is bug 166862 related? (found by njyoder)
(In reply to comment #10) > the test image that was in the bug is now gone ;/ can someone find another > version that breaks? http://ha.ckers.org/imagecrash.html crashed me 5 minutes ago. The image is only 640x480 in size, here's the source if the page goes down: <HTML> <BODY> <IMG SRC="./imagecrash.jpg" width="9999999" height="9999999"> </BODY> </HTML> That's it. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
*** Bug 295383 has been marked as a duplicate of this bug. ***
This appears OK on the Deer Park Alpha, could it be fixed by the large-value colspan/rowspan bug 141818?
(In reply to comment #16) > This appears OK on the Deer Park Alpha, could it be fixed by the large-value > colspan/rowspan bug 141818? No: despite the testcase similarity of using "9999999" attribute values to cause a crash, that fix was specifically to the colspan and rowspan attribute parser.
Created attachment 184497 [details] [diff] [review] Patch to improve robustness in the face of erroneous user supplied data Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050517 Firefox/1.0+ The testcase in comment 8 crashes for me. Whilst testing this, I found the following code path: The function nsLineLayout::FreeSpan(PerSpanData* psd) at http://lxr.mozilla.org/seamonkey/source/layout/generic/nsLineLayout.cpp#733 can be called with the argument psd containing null. Since we try to dereference it, I suggest this guard
Created attachment 184498 [details] [diff] [review] Patch to improve robustness in the face of erroneous user supplied data Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050517 Firefox/1.0+ The testcase in comment 8 crashes for me. Whilst testing this, I found the following code path: The function nsLineLayout::EndLineReflow() at http://lxr.mozilla.org/seamonkey/source/layout/generic/nsLineLayout.cpp#350 can be called with the member mRootSpan already nsnull. It seems unnecessary to 'Free' it, or most probably to do anything else, I suggest this guard.
Created attachment 184499 [details] [diff] [review] Patch to improve robustness in the face of erroneous user supplied data Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050517 Firefox/1.0+ The testcase in comment 8 crashes for me. Whilst testing this, I found the following code path: At http://lxr.mozilla.org/seamonkey/source/layout/generic/nsLineLayout.cpp#830 we initialise the local variable psd an use its value on the next line, unfortunately, it is possible for psd to contain null at this point. I suggest this guard. Now it is my belief that these patches are well downstream of the site of the cause of this crash, but while it is easily reproducible, I can take the opportunity to add some error handling.
i haven't tryed these specific test cases, but this one http://www.tinyurl.com/dsprr crashed mine. note this one somehow puts up an away message w/ the url if you have the offical version of aim, luckly i use gaim so it didn't work on me. I noticed it crashes my laptop, 2.8GHz Pentium 4 HT, 512MB ram (with 64 MB shared video memory, ATI Radeon Mobility 9000) caused BSOD, and caused my graphics driver to crash same thing on my desktop, 3 Ghz Pentium 4 HT, 512MB RAM, 256 MB Radeon 9800, 512 MB ram. it seems to be an all-browser exploit, works on IE too.
This appears to be fixed on the trunk. If we can get some help identifying the build that corrected the crash on the trunk that would be great because it might give us the checkin that fixed things there. if that's a simple fix, then we can consider taking that on the branch.
Another site using this trick: http://winboot.mine.nu/ Opera does not crash.
*** Bug 297554 has been marked as a duplicate of this bug. ***
*** Bug 297695 has been marked as a duplicate of this bug. ***
*** Bug 297701 has been marked as a duplicate of this bug. ***
*** Bug 297879 has been marked as a duplicate of this bug. ***
*** Bug 298034 has been marked as a duplicate of this bug. ***
*** Bug 298080 has been marked as a duplicate of this bug. ***
*** Bug 298147 has been marked as a duplicate of this bug. ***
Apparently Microsoft fixed this in their latest round of windows security updates: In looking for what might have fixed this on the trunk I walked back to the branch point, then out the branch all the way to the release I know I used to confirm this bug (several times in different test cases). I'll have to find an unpatched system to try to narrow this down (or we could just point fingers at Microsoft and ignore it since the upcoming 1.1 had this fixed anyway).
On Win XP this was fixed between 2005-03-04-07-trunk and 2005-03-05-07-trunk. Not exactly sure when the nightlies pull, but the fix is definitely in this range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-03-04+04%3A00&maxdate=2005-03-05+08%3A00&cvsroot=%2Fcvsroot The only fix that jumps out at me is Paper's patch for bug 284716. That patch looks like it's Win2k/XP only -- does Win98/ME crash on these testcases in 1.0.x, and if so does it still crash in Deer Park? (QA note: the latest microsoft security updates, for winxp at least, appear to also block this crash. Make sure you test a windows box without the latest updates).
(In reply to comment #32) > The only fix that jumps out at me is Paper's patch for bug 284716. That patch > looks like it's Win2k/XP only -- does Win98/ME crash on these testcases[?] The patch for bug 284716 stops the crash on Win XP (both Firefox and Mozilla 1.7), I recommend we take it for the branches. Doesn't look like it will help Win98, but it's not been confirmed the problem exists there.
We're not going to take this on the branches, the fix for bug 284716 caused regressions and is snowballing into a bigger change than we're comfortable with for a security release (it just moves the DOS somewhere else). The crash is fixed on the trunk. People not ready to upgrade to the alpha-quality trunk can apply Microsoft's June 2005 security updates and protect themselves.
In reply to Comment #31 From Daniel Veditz 2005-06-19 10:38 PDT : > Apparently Microsoft fixed this in their latest round of windows > security updates It still occurs on up to date WinXP . Also , we have only found this in WinXP . Not in Win2k , or Win98/ME .
(In reply to comment #35) > In reply to Comment #31 From Daniel Veditz 2005-06-19 10:38 PDT : > > Apparently Microsoft fixed this in their latest round of windows > > security updates > It still occurs on up to date WinXP . Confirmed the crash still occurs on another fully updated machine (on the 1.0.x branch). I guess the fact that my main dev machine no longer crashes is just a happy accident, not an intentional fix in the latest Microsoft updates.
Setting blocking1.7.9 and blocking-aviary1.0.5 per 1.0.5 meeting.
This bug is currently marked fixed , but it is not fixed in 1.0.x ENV: firefox/nightly/2005-06-23-05-aviary1.0.1/firefox-1.0.5.en-US.win32.installer.exe 23-Jun-2005 08:29 4.6M still repros the issue (on a WinXP up to date) computer (with one of the numerous video h/w cfg that is exposed to this MS bug) . Other than CSS are there other interesting variations of the testcase ?
Created attachment 187146 [details] alt testcase : WinXP html using large IMG dimensions via CSS Alternate testcase : WinXP html using large IMG dimensions via CSS
Lloyd: It is marked fixed because this is fixed on the Trunk. That is how we track progress on the development tree. The "blocking-aviary1.0.5+" and "blocking1.7.9+" flags are used to track whether or not we need to fix this on the branches (eg. Firefox 1.0.x). We are looking into fixing this for those releases.
*** Bug 298641 has been marked as a duplicate of this bug. ***
*** Bug 298660 has been marked as a duplicate of this bug. ***
*** Bug 298781 has been marked as a duplicate of this bug. ***
Pav is putting together the necessary Trunk patches (from bug 284716 and any resulting regressions) that need to land on the branches. Those changes should fix this problem and provide some performance enhancements as well.
reopening to assign to Pav
Re-closing fixed on the trunk. The fix (bug 284716) had regressions. This is a good place to gather all the necessary patches in one place.
After reading through bug 284716 and a few regression bugs mentioned there, it looks like we at least want the following patches on the branches: 1. Bug 284716 (https://bugzilla.mozilla.org/attachment.cgi?id=176232) 2. Bug 284978 (either https://bugzilla.mozilla.org/attachment.cgi?id=176528 and/or a work in progress, which requires both https://bugzilla.mozilla.org/attachment.cgi?id=182038 and the patch in bug 292051) Not sure if anything in bug 205893 or bug 204374 is needed here...but might be worth a look. If all we need are the 2 patches I found, let's try to get them in tonight so we can have a day of regression testing.
Fix from bug 284716 checked into 1.7 and aviary branches. First patch from bug 284978 regression fix checked in to branches.
*** Bug 299355 has been marked as a duplicate of this bug. ***
v.fixed on aviary with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050706 Firefox/1.0.5
may not be fixed... knoxvegas reports on IRC that he's still crashing with a 20050706 trunk firefox build. http://www.tabwin.com/puss.html http://www.jgiannotti.com/pwned http://llama.i.am/ http://www.jgiannotti.com/pwn
Tested at this time using link http://home.tu-clausthal.de/~inmc/esg/iecrash.html (basic test case) and on one of our "vulnerable" boxes : Video Card VIA/S3G UniChrome Pro IPG Driver Version 18.104.22.168 Date 6/8/2004 nightly/2005-07-06-20-trunk/firefox-1.0+.en-US.win32.installer.exe results in bluescreen , but nightly/2005-07-07-05-aviary1.0.1/firefox-1.0.5.en-US.win32.installer.exe did NOT . Firefox was unresponsive for a short period of time , but OS remained functional .
*** Bug 300288 has been marked as a duplicate of this bug. ***
Two more sites that crash Windows XP SP2 with all patches using Firefox: http://www.cheater4ever.de.vu/ http://www.hunger.hu/win.html I think it becomes really a serious issue since more and more sites are using it. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050710 Firefox/1.0+ ID:2005071006
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050710 Firefox/1.0+ ID:2005071006 Using http://www.hunger.hu/win.html Windows gave me a stop error for my video card. Of course I have all the latest crap on it, so I'm not even going to go into that, albeit my vid card is only 16 megs, it doesn't crash on other links like comment 51 (but I haven't tried the first link comment 54) I'm not testing any other links. The stop error says my video card goes into an endless loop. 9999999 squared pixels should not be parsed: There should most definitely be a limit set. Make a default setting of 10000 pixels, and if a user needs to change it, then they can change it at their own risk.
Here is my experience with this bug. Maybe this will give some clues (Windows XP, SP2; P3 933 MHz; 512 MB RAM; GeForce2 MX): 1. Deer Park Alpha 1, June 19 Trunk a) NO CRASH whatsoever for above posted URLs *EXCEPT* http://home.tu-clausthal.de/~inmc/esg/iecrash.html with many extensions. Tested this bug back in June and tested again today. 2. Deer Park Alpha 2, July 10 Trunk a) Safe Mode: NO CRASH b) Normal Mode: CRASH - (with clean profile or profile having many extensions 3. Internet Explorer a) CRASH
(In reply to comment #56) > Here is my experience with this bug. Maybe this will give some clues (Windows > XP, SP2; P3 933 MHz; 512 MB RAM; GeForce2 MX): > > 1. Deer Park Alpha 1, June 19 Trunk > a) NO CRASH whatsoever for above posted URLs *EXCEPT* > http://home.tu-clausthal.de/~inmc/esg/iecrash.html with many extensions. Tested > this bug back in June and tested again today. > > 2. Deer Park Alpha 2, July 10 Trunk > a) Safe Mode: NO CRASH > b) Normal Mode: CRASH - (with clean profile or profile having many extensions > > 3. Internet Explorer > a) CRASH while testing did u restart ur comp between testings? if not the results may be askew. just sayin...
> while testing did u restart ur comp between testings? > > if not the results may be askew. > Not Likely. Hightly and consistently reproducible. Order of testing does not matter. Each one of those individual tests has been performed at least once (as the first test) after a restart.
Once again, I am not crashing at any of the URLs mentioned in the past 7-8 comments. Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050709 Firefox/1.0.5 (and I have SP2 installed)
*** Bug 300480 has been marked as a duplicate of this bug. ***
*** Bug 300461 has been marked as a duplicate of this bug. ***
Don't know if you know this or not but it seems that StretchBlt(...) is causing the BSOD. The graphic card is trying to stretch that image to 9999999, causing watchdog to think that the device driver is spinning in an infinite loop. Resulting in a bugcheck... debug trace: THREAD_STUCK_IN_DEVICE_DRIVER (ea) Debugging Details: ------------------ FAULTING_THREAD: 89261678 DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT BUGCHECK_STR: 0xEA LAST_CONTROL_TRANSFER: from 8080c9ce to 808047f3 STACK_TEXT: f752ffc0 8080c9ce f78bab40 f78bab70 00000000 nt!KiUnlockDispatcherDatabase+0x77 f752ffd4 f77dfa67 f78bab94 00000000 00000000 nt!KeSetEvent+0x74 f75302c8 80819282 f78bab40 f7530314 f7530308 watchdog!WatchdogKernelApc+0x13b f7530318 80a17c35 00000000 00000000 f7530330 nt!KiDeliverApc+0xb3 f7530318 bf95d2c2 00000000 00000000 f7530330 hal!HalpApcInterrupt+0xc5 f75303bc bf85e9f3 008325d9 0391e233 0391d5f4 win32k!pxrlStrRead24+0x7d f7530610 bf89e1d4 f7530574 00000000 00000196 win32k!EngStretchBlt+0xb1b f75306b0 bf89dfc5 e18b1e90 e1687e90 00000000 win32k!EngStretchBltROP+0x3a5 f753078c bf846fc4 00000000 00000000 bf89e146 win32k!BLTRECORD::bStretch+0x41b f75308c0 bf835c0c 01010057 0000000c 00000011 win32k!GreStretchBltInternal+0x632 f75308fc 808077ec 01010057 0000000c 00000011 win32k!GreStretchBlt+0x30 f75308fc 7c90eb94 01010057 0000000c 00000011 nt!KiFastCallEntry+0xf8 WARNING: Frame IP not in any known module. Following frames may be wrong. 031eb2bc 00000000 00000000 00000000 00000000 0x7c90eb94
behavior has improved on recent builds, many of the rogue sites are no longer crashing deer park latest trunk 20050712 - however, this one particular site uses a variant that is still crashing Firefox a2 badly. This is the really troublesome site: http://www.hunger.hu/win.html if it doesn't crash your system the first time, try reloading that same site 3 or 4 times.
(In reply to comment #62) Wrong function in my post.. Should be StretchDIBits(...) whats causing the bugchecks. Ignore that stack trace, that one is from IE...
Since this still occurs on the trunks, isn't it the case to reopen this bug? A discussion about this issue was started on MozillaZine: http://forums.mozillazine.org/viewtopic.php?t=291127
*** Bug 300665 has been marked as a duplicate of this bug. ***
Quick hack to fix this: --- D:\CVS\mozilla\gfx\src\windows\nsImageWin.cpp Thu Jul 14 04:22:12 2005 UTC +++ D:\CVS\mozilla\gfx\src\windows\nsImageWin.cpp Thu Jul 14 04:26:12 2005 UTC @@ -469,6 +469,14 @@ if (0 == aSWidth || 0 == aDWidth || 0 == aSHeight || 0 == aDHeight) return NS_OK; + + // Hack: limit the amount we can stretch an image. + if ((aSWidth*4) < aDWidth) + aDWidth = aSWidth*4; + if ((aSHeight*4) < aDHeight) + aDHeight = aSHeight*4; + + if (mDecodedX2 < mDecodedX1 || mDecodedY2 < mDecodedY1) return NS_OK;
Hmm, that wasn't a very good hack.. This is probably better: + if ((aDWidth > 0xFFFF) || (aDHeight > 0xFFFF)) // 64k + return NS_ERROR_FAILURE;
dbaron, can you help us figure out a reasonable size to clamp this down to avoid the crash?
I've found a page that cause massive memory leak, probably it's a page with oversized image, could somebody check it (if it isn't oversized image i'll fil new bug)? http://www.pmscollege.org/previous/hello.htm
Regarding , Comment #70 leak or bloat ? Anyway , looking @ the source of that page , I do not see a relationship to this bug's issue .
*** Bug 307577 has been marked as a duplicate of this bug. ***
hi, just wondered if anyone on this thread had taken a look at: https://bugzilla.mozilla.org/show_bug.cgi?id=307577 it's just been closed as a duplicate of this bug but seems to do with character encoding rather than oversized images. the results are the same though - blue screen of death. i was mostly wodering if anybody else had the same problem with the attached files (on the duplicate bug) or if it was just me. Be warned though, if you do have the same problem as me it will crash your system.
*** Bug 314574 has been marked as a duplicate of this bug. ***
I'm willing to bet the cause of this isn't the image dimensions directly, but rather the raw size of the stretched image. In my experience XP will crash if you run out of video memory very quickly (with low-capacity cards this can be seen by viewing a directory with hundreds of images in Thumbnail view). Thus it may help to have Firefox query how much video memory is available and not attempt to render any image which won't fit into memory. However, this needs to be implemented carefully as there is a race condition (available memory may decrease after it is measured but before the image renders). Barring that, a simple workaround would be to implement a user pref specifying a limit on image size. Given the bit depth and dimensions, it should be possible to calculate the raw size of the stretched image, and refuse to render it if it exceeds this limit.
I believe the problem starts with 5000px times 5000px original image dimensions. Here is the original exploit URL. http://ha.ckers.org/imagecrash.html
*** Bug 354783 has been marked as a duplicate of this bug. ***
This doesn't crash vista, is this fixed on winXP ?
got an email from "wild Bill" : >yes, has been fixed on XP for quite some time :) marking wfm
crash test landed http://hg.mozilla.org/mozilla-central/rev/4e3d7a4d0b77