Closed Bug 115788 Opened 24 years ago Closed 23 years ago

xfs remote DoS with Mozilla

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 150339
Milestone:
mozilla1.1alpha

People

(Reporter: mikko.rapeli, Assigned: attinasi)

Details

Attachments

(2 files)

Mikko: would you? Kindly attach the html to this bug xfs_dos_with_mozilla.html
1.59 KB, text/html
Details
xfs_dos_with_mozilla.log with NS_FONT_DEBUG="1D"
114.61 KB, text/plain
Details
---------- Forwarded message ---------- Date: Mon, 17 Dec 2001 12:42:25 +0200 (EET) From: Mikko Rapeli <mikko.rapeli@iki.fi> To: security@xfree86.org, mozilla-security@mozilla.org Subject: xfs remote DoS with Mozilla Hi! I crashed my RedHat Linux 7.1 box once when viewing one of my handwritten web pages, and after some debugging is seems that bad html on Mozilla starts xfs font server spinning out of control. xfs eats all CPU time and memory after opening the page with Mozilla, which seems to be asking for larger and larger fonts. Perhaps someone from xfree or mozilla lists can debug the details. There is a bug in Mozilla when viewing this kind of page, but xfs still should not go crazy. I did not have time to install newer versions of Xfree, but at least http://www.xfree.org/security/ does not show a fix for this. Linux setup: $ uname -a Linux lnx 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown $ X -version XFree86 Version 4.0.3 / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 16 March 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Operating System: Linux 2.2.17-8smp i686 [ELF] Module Loader present $ mozilla -version Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120, build 2001112012 $ mozilla -version Mozilla/5.0 (X11; N; Linux 2.4.2-2 i686), build 2001031614 The 'not-that-bad' html page: $ perl -e 'print "<HTML>" x 1; print "<BODY>" x 1;print "<CENTER><P><H3>A" x 100; print "</BODY>" x 1;print "</HTML>" x 1' top log: <snip> 4:07pm up 23:08, 6 users, load average: 0.02, 0.06, 0.02 1 processes: 1 sleeping, 0 running, 0 zombie, 0 stopped CPU states: 2.7% user, 0.8% system, 0.0% nice, 44.8% idle Mem: 125640K av, 122956K used, 2684K free, 0K shrd, 1604K buff Swap: 208804K av, 99844K used, 108960K free 64972K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 1208 xfs 9 0 73100 27M 20948 S 0.0 22.4 17:18 xfs 1208 xfs 9 0 73100 27M 20948 S 0.0 22.4 17:18 xfs 1208 xfs 17 0 73100 30M 23816 D 45.3 24.5 17:19 xfs 1208 xfs 17 0 73100 27M 24080 D 30.0 22.1 17:20 xfs 1208 xfs 15 0 73056 31M 29092 D 15.1 25.7 17:20 xfs 1208 xfs 15 0 73056 34M 32284 D 12.1 28.3 17:20 xfs 1208 xfs 17 0 73056 39M 37056 D 6.6 32.1 17:20 xfs 1208 xfs 17 0 73056 42M 39852 D 2.4 34.3 17:20 xfs 4:08pm up 23:09, 6 users, load average: 0.54, 0.16, 0.05 1 processes: 1 sleeping, 0 running, 0 zombie, 0 stopped CPU states: 4.3% user, 7.1% system, 0.0% nice, 88.5% idle Mem: 125640K av, 122436K used, 3204K free, 0K shrd, 404K buff Swap: 208804K av, 114312K used, 94492K free 63136K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 1208 xfs 17 0 73056 45M 43728 D 5.7 37.4 17:21 xfs <had to killall mozilla-bin to avoid out-of-mem, snip> It seems that neither xfs nor Mozilla have any real security holes, since Mozilla only asks for larger and larger fonts. However, this is way too easy to reproduce, and when the xfs dies the whole X session becomes unstable... Regards, -Mikko
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120, build > 2001112012 > Mozilla/5.0 (X11; N; Linux 2.4.2-2 i686), build 2001031614 Were two mozillas tested? Or is only one of those correct?
Assignee: asa → attinasi
Component: Browser-General → Layout
QA Contact: doronr → petersen
Yes, both version were tested, so the bug (or feature) has been there for a while. -Mikko
confirming. If nothing else, we should not be requesting "bigger and bigger fonts" in this situation.....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mikko: would you? Kindly attach the html to this bug Kindly: set the environment variable NS_FONT_DEBUG to 1D do a minimal run (eg: ./mozilla http://your_web_server/your_page) attach the output to this bug --- changing OS to Linux cc:'ing ftang
OS: Windows 2000 → Linux
Kindly attach the html to this bug xfs_dos_with_mozilla.html Be carefull on a Unix machine, this DoS'es mozilla and xfs! On Windows it just looks weird...
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 Done with: $ export NS_FONT_DEBUG="1D" $ mozilla localhost/xfs_dos_with_mozilla.html &> xfs_dos_with_mozilla.log
Target Milestone: --- → mozilla1.1
This bug is still present in Mozilla 1.0rc2 under Linux. I encounter it every now and then, although usually not to the extent provoked by Mikko's sample HTML. Typical scenario is that I start loading a "strange" page (often with Far East characters), and Mozilla hangs for about a minute with high system VM I/O. top(1) shows xfs(1) hard at work, and a rapid climb in the X server's memory consumption (often to over 250MB+). Lots and lots of disk thrashing. And of course, the memory isn't released until Mozilla is exited---not good if you have 20+ open tabs of unbookmarked pages that you want to read at a later time.
This one is fairly painful. xfs, xfs-xtt, and XFree86 on my system all spiked to nearly 300MB. Nothing crashed, though, and I've got that page open (and displayed) in another tab while making this comment ;-) Anyway, the problem here isn't mozilla's treatment of invalid HTML. It's that Mozilla requested a extremely huge font from the X server. It must be requesting 20,000pt fonts by but twenty pages down. I'm only a few pages down and the A's are three screens tall! Even if Mozilla handled this broken HTML differently, this attack could still be pulled of by CSS. BTW: The font servers free the memory quickly. X, on the other hand, is still 182M (but only a RSS of 11M).
Confirming that attachment crashes RC3 (yeah, I know I need to upgrade...) under Linux (Mandrake 7, XFree4). Only Mozilla crashed; everything else is fine. Still... Is there any good reason not to limit the max font size to the value of some pref, and set the pref to 4096 or so by default? Or would that just be fixing a symptom? Is there a situation where well-beyond-enormous fonts (such that a single character won't begin to fit on any common paper size or screen res) are actually needed?
*** This bug has been marked as a duplicate of 150339 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: