A small XML document that expands to a huge document after entity expansion can hang and eventually crash Mozilla. The document at the test URL would expand to 2 billion characters (if it could). While the document is being expanded the browser is completely hung, not even refreshing the window, so the only recourse is to kill it or wait until it runs out of memory and crashes.

confirming that the given URL hangs with 2002080208 trunk on win2k

No sane document would do this, and as far as attacks go this isn't very good. It is possible to provide huge inputs for Mozilla in many other formats as well and completely exhaust the resources on the system, and cause a crash. Futuring for now, but if this becomes a serious issue or someone would like to provide a patch I can take a look. Stack trace of where it crashed could also help.

Though it is possible to hang Mozilla by providing huge inputs, it is usually possible to interrupt the loading of those huge inputs. This isn't a huge document, it's a small document that expands to a huge one, and you can't interrupt it.

FWIW, Heikki, here's a MacsBug stdlog. I entered MacsBug when the system hung.

(In reply to comment #2) > No sane document would do this, and as far as attacks go this isn't very good. > It is possible to provide huge inputs for Mozilla in many other formats as well > and completely exhaust the resources on the system, and cause a crash. > > Futuring for now, but if this becomes a serious issue or someone would like to > provide a patch I can take a look. Stack trace of where it crashed could also help. I have seen this problem too, with the rendering of 3MB xml files, whether it is sane or not to do this, the question is why is firefox using 100% of the cpu and unresponsive (ie it doesnt repaint the screen) it does eventually render the document after 2 minutes of waiting. The stop button doesnt work in 1.5.8 on linux however when I tested in 2.0 it did after a time. I think there are several problems, 1) there seems to be a serious problem with rendering in firefox, the rendering of one window/tab blocks the rest of firefox, I dont know if you do but it would be good to use a thread pool to render the windows. The bottom line is that the browser should never be unresponsive to user interaction (ie clicks on stop or changing tabs) and should always repaint the screen (even if the screen is blank with a message saying Rendering). In my opinion the user should be free to load any size file and firefox should deal gracefully with that, for example loading the first part of a 1GB file and popping up an error message saying Out of Memory. 2) firefox should test the size of an xml document if its small render it as a tree (as normal) if its large then a) render it as plain text or b) render the root node of the xml DOM and let the user expand nodes. (I think plain text would be better) This bug really should be looked at urgently I can send you the 3MB file if you like but I think any large xml file will create the same problem. Andy Bailey

layout is limited to a single main thread. no pool. fixing this is amazingly non trivial.

there's no way this is a top priority. we have hundreds of other more important bugs. if it's important to you, pull from cvs, read all about layout and start thinking about hacking it yourself.

Pretty sure Heikki isn't working on this. Unassigning to make this show up on searches for unassigned bugs.

erahm, Is this even worth pursuing in the expat context? Is the replacement for expat expected to have protection against billion laughs? What's the ETA for the replacement? FWIW, the expat maintainer was looking for funding for built-in billion laughs protection for expat in August: https://www.xml.com/news/2017-08-expat-224-released/ , which suggests a good fix for expat wouldn't be super-simple. (I spent a bit of time examining the code flow in rr and decided not to pursue a fix.)

(In reply to Henri Sivonen (:hsivonen) from comment #12) > erahm, Is this even worth pursuing in the expat context? Is the replacement > for expat expected to have protection against billion laughs? What's the ETA > for the replacement? > > FWIW, the expat maintainer was looking for funding for built-in billion > laughs protection for expat in August: > https://www.xml.com/news/2017-08-expat-224-released/ , which suggests a good > fix for expat wouldn't be super-simple. (I spent a bit of time examining the > code flow in rr and decided not to pursue a fix.) There's also bug 1276704. Since this is just a DoS it's not high priority, but it seems like just adding an entity cap or recursion cap might be an improvement. RE: replacement, hoping to start in Q4 but that's subject to approval. RE: expat, I sent the maintainer a suggestion that they apply for a MOSS grant to get funding to work on these types of things.