Open Bug 901536 Opened 12 years ago Updated 2 years ago

An evil (zipbomb) page with a large amount of content in the title locks up firefox, and also locks up about:sessionrestore when firefox is killed.

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

People

(Reporter: bugs, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

Attachments

(1 file)

Screenshot of what the browser looks like after zipbomb_light.html loads
31.94 KB, image/png
Details
So, I was experimenting with this page to mess with a friend's bot, and accidentally discovered it did bad things to my Firefox session. It appears Firefox has no sanity constraints on page title lengths. This page consists of: <html><head><title>[1GiB of 0x00 here]A</title></head></html> I'm not going to link it in the demo link to discourage people clicking on it willy-nilly. The URL to the page is: http://m8y.org/tmp/zipbomb/test.html and the directory is open, so you can look inside (http://m8y.org/tmp/zipbomb/) What happened when I clicked on it. Firefox completely froze up (entire UI). Memory usage shot up to around 6GiB and CPU maxed out. It stayed this way for about 15 minutes, at which point I was able to switch to another tab (the memory usage stayed high). At this point, I could browse normally in other tabs. The evil tab title, interestingly, was overflowing its tab, overlaying the "text" of the diamonds indicating the nulls on the tabs to the right, and the [+] button for new tabs. I thought to drag it further to the left to see if this could extend from one side of the browser to the other, and while holding down left click to drag the tab, the browser went back to 100% CPU usage and locking up. After a while, I gave up and killed Firefox and restarted it. On restart, I saw the about:home page, then the url immediately shifted to session:restore. However, the page did not change and I realised it wasn't repainting. That it had frozen up again, and memory usage was spiking. After about 15 minutes the session:restore page finally loaded, and I tried unchecking the evil tab. This attempt to interact with the line entry in session:restore once again froze up the page. I gave up, killed Firefox again, verified it happened reproducibly a few times, then erased the profile. Before I erased it, I noted that the session restore files were around 800 megabytes in size, each.
I didn't realise bugzilla was going to make the links in the description clickable anyway, so I tossed in a wrapper page. Click on the prominent link on the wrapper page to mess up your profile.
URL: http://m8y.org/tmp/zipbomb/test.html
Crashes... Nightly win32 build bp-43752f89-25f9-4495-a20f-9efa62130805 http://hg.mozilla.org/mozilla-central/rev/482b9d04974a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 ID:20130805030205
Yeah, I imagine crashing versus locking up depends on how much memory your system has (I have 16GiB) and whether Firefox is 32 bit or 64 bit (I'm using 64 bit under Linux). The size of the page may be a bit excessive to demonstrate these effects, might work just as well with, say, a 100 megabyte version. I can make that pretty easily if anyone cares.
Added a 100MiB "light" version of the zipbomb. The Firefox instance where I loaded it is using 2.5GiB of RAM. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23520 nemo 20 0 3775m 2.5g 43m R 99.6 15.9 4:45.83 firefox I'm mildly surprised actually, since I expected it to use 1/10th the memory. Should still manage to load on 32bit Windows Firefox though. At least it saves me some bandwidth. ☺ -rw-r--r-- 1 nemo web 1018K Aug 5 11:08 zipbomb.html.hgz -rw-r--r-- 1 nemo users 100K Aug 5 12:13 zipbomb_light.html.hgz Right now it is churning away. If it finishes "loading" I'll see if I can get a screenshot of the tab bar ugliness.
So, this was mildly challenging to grab, since doing almost anything that triggered a repaint resulted in Firefox maxing out CPU for a couple of minutes. Ended up dumping it using xwd.
Updated http://m8y.org/tmp/zipbomb/test.html based on my experiments in Chrome.
Summary: An evil (zipbomb) page with a large amount of content in the title locks up firefox, and also locks up session:restore when firefox is killed. → An evil (zipbomb) page with a large amount of content in the title locks up firefox, and also locks up about:sessionrestore when firefox is killed.
Could you get a profile[1] of what's going on while this is trying to draw the tab title, and while bringing up or refreshing about:sessionrestore? I'm curious whether it's textrun construction, for example, that's consuming all the CPU, or some other aspect. [1] https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler
Heh. Will the builtin profiler really function if Firefox is sucking up all my memory and CPU? I guess if I waited long enough? Wait, why don't you try it? :-p Odds of me getting around to it today aren't terribly high and I'll be out on vacation starting tomorrow.
SPS Profile against Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20130927030202 CSet: 3ad5ecf34c9e for the "just load the Testcase for the 1st time and wait a few Seconds" Case: http://people.mozilla.org/~bgirard/cleopatra/#report=7a7043d5c3bfe51bf0168eec56921c1add25bfdc
It looks like nearly 50% of the time is spent in textrun construction under nsTextBoxFrame::DrawText. I think this is a symptom of the implementation of nsTextBoxFrame, which does not cache the textrun for its content, but recreates it for every measurement or draw operation that it needs to do. (Over 20% of the time is also spent in textrun construction under nsTextBoxFrame::DoLayout. I suspect a good deal of that is redundant, too, though to be sure of this we'd need to know whether a given nsTextBoxFrame is being re-measured multiple times.) Bug 837765 was filed about this inefficiency in nsTextBoxFrame. If we get that fixed, it should have a significant effect on this example.
Depends on: 837765
Component: Session Restore → Tabbed Browser
OS: Linux → All
Hardware: x86_64 → All
Hrm. Why was this moved out of Session Restore? While it seriously screws up tabbed browsing to be sure, if it simply did that it would be no big deal. Kill it, restart it, go on with life. The problematic part is when trying to recover your old session and about:sessionrestore (which as no tabs) is completely locked up trying to parse those same loooong strings which are untruncated in the session restore. As noted in the comments, the session restore files were one and a half gigs, total. That's probably even problematic on mobile?
Well, maybe it is two independent bugs, one is of Tabbed Browser, the other is of Session Restore, and the latter might be more serious since it could lead to a crash loop. After looking into the code, I believe that they are both caused by the same old inefficient implementation of text cropping, in nsTextBoxFrame and nsTreeBodyFrame respectively (the former is discussed in bug 837765). And locking firefox itself might be another bug that any piece of rendering code executes for a long time will freeze the whole firefox. I have no idea what component exactly should this bug belong to. Maybe you are right that this bug should be in Session Restore.
Component: Tabbed Browser → XUL
Product: Firefox → Core
Hrm. Well, cropping wouldn't be an issue, surely, if the text was truncated in the first place? There's no reason that the title bar or session store should be trying to save-to-file/display a gigbyte, or even a megabyte, worth of text. Seems to me 2 kilobytes (a page of text) is surely sufficient, even w/ multibyte chars. As noted, chrome appears to truncate in session store, (although not, I assume, in title bar, from chrome's even greater fragility in that regard). I suppose there's maybe some DOM reason that Firefox has to hang onto the whole string, but that surely doesn't extend to making use of that exact same string in the titlebar/session store.
Hm. I'm having trouble reproducing this in nightly, I think 'cause Firefox is being a tad smarter. In a clean profile, after hitting the page, I get a spike up to 4.4GiB of RAM and 100% CPU usage. After a while the page renders w/ '3333333333333333333333' in the title as expected. Memory usage then drops back down to about 1.5GiB and things become responsive. I kill FF, restart, and instead of leaving me on the zipbomb page, it puts me on the page before. I hit the zipbomb, memory spikes, but almost immediately falls off, and the page renders without title. Refreshing causes a bit of a CPU spike, and memory spike, but you guys seem to have done something about this.. At any rate, having difficulty finding out if it is being written to session store insanely large. 4.4GiB of RAM is still a lot and would have crashed a 32 bit machine, but I'm not getting the original behaviour anyway.
Still crashes all my e10s tabs and has the layout corruption. I was testing this bug again because I noticed someone deeplinking the evil pages based on Facebook external hits. I moved the test pages to behind the password zip/bomb to avoid accidental clicks. Thanks Gijs for the suggestion.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: