PoC
You can try loading this directly in chrome or 
host it on a web server and access it via address bar in chrome

Deleted: Test.xml 853 bytes

Test.xml 853 bytes View Download

Mozilla Firefox handles this well with below message:
XML Parsing Error: recursive entity reference

Internet Explorer behaves stably without causing increase in memory usage.

Addition Details on Chrome:
After some time with the billion laugh xml open, chrome becomes unresponsive with propmt to kill the tab

Thanks for your report.  We track browser DoS as a functional bug, rather than a security issue per-se.  Removing restrictions.

====================================

Good Build:

47.0.2505.0   Base Position: 347815


Bad Build:

47.0.2506.0   Base Position: 348053

=====================================

Able to repro this issue on Windows 7, MAC (10.11.4) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 49.0.2623.112

This is a regression issue broken in M47, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/3903f745bb79ac3045688557be9d51b142b29a25..0c2036dbfa8177857e0df81de7a4bb34023300b5 

https://chromium.googlesource.com/chromium/blink/+log/62591a8..a939e61

https://chromium.googlesource.com/chromium/blink/+/a939e6184a192e91b0088052269554c8866dacad

Suspecting Commit: a939e6184a192e91b0088052269554c8866dacad			

Review URL: https://codereview.chromium.org/1316673007

@scottmg: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

I'm not sure if there's anything do to here. I gather this is just `while(1) x+='a';` (?) which I'm sure there are many ways to do in xml/xslt.

Thank you for filing this well-written bug report. We actually get billion laughs reported from time to time; our fuzzer ClusterFuzz discovers it occasionally too. So from that point of view it would be nice to fix.

On the other hand, billion laughs is annoying at most. It basically exhausts memory (slowly) and there are lots of ways to do that in the web platform.

Details:

This is not recursive in the sense that any of these entities refer to themselves. The're just entities that expand to exponentially large content. libxml detects recursive entities, which you can see with this URL:

data:text/xml,<?xml version="1.0"?><!DOCTYPE echo [<!ENTITY hi "hello &hi;">]><greeting>&hi;</greeting>

We can't use DtdProcessing.Prohibit to mitigate this, because Chrome uses libxml for parsing XML and DtdProcessing.Prohibit is a .NET XML parser thing.

I think libxml has some heuristics for preventing billion laughs, if you search the codebase for XML_PARSER_LOT_ENTITY and XML_PARSER_NON_LINEAR. I have not studied in detail why they are not effective here.

Thanks for acknowledging the DoS issue.
Would you be allotting a CVE-ID for this defect? 
Considering that similar DOS attacks already have CVE-Ids:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1821

The CVSS for this issue based on my understanding is defined below:
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L/E:P/RC:R

I doubt that--this doesn't really deny service. I will label this as a security bug; someone on the security team can comment definitively.

Attached is the Video the flow along with showing crash and continuous memory rise in chrome.exe.

Deleted: chrome.wmv 1.9 MB

chrome.wmv 1.9 MB Download

 Issue 616444  has been merged into this issue.

616444 is not visible to me

It's the same bug--use entities to make an XML file that takes exponential resources to process.