Talk:Billion laughs attack

Quickly created

This was quickly created without much effort since there wasn't even any page about it before. It should most likely be merged with the DoS-attack page when it has reached proper wikipedia standards.

I am aware that the article is not totally up to standard, but that's because I am not an expert in this area. I came here looking for an article because my Ubuntu OS wanted to install an update protecting against this kind of attack, and I did not know what it was. --Eyetoy2 (talk) 12:16, 12 June 2009 (UTC)

If this is still under construction shouldn't it have a tag on it or be in a user page as it doesn't merit a full article.Jamesrules90 (talk) 15:22, 13 January 2010 (UTC)

I disagree. I believe this article is very useful and its content is well redacted and relates well to this particular type of attack. Additionally, a reference from the DoS attack page was most welcome, as Billion laughs are a sub kind of attack. Great article. Live2create (talk) 06:44, 8 December 2010 (UTC)

The statement about references is wrong: References are fine because (by definition) the referred-to object is created at definition time and just linked up, not duplicated. The YAML example should not pose any special problems, unless the YAML parser used has a bug and indeed creates another copy for every reference. I think the word "reference" should probably replaced by "macro expansion" or something; I don't know the best word to use for that. 84.72.0.73 (talk) 05:45, 23 February 2017 (UTC)

In the YAML example, what would happen if you tried to retrieve the value of i?

ApLundell (talk) 06:36, 23 February 2017 (UTC)

irb(main):037:0> a = YAML.load(y) ; a.class

=> Hash

irb(main):038:0> a["i"].class

=> Array

irb(main):039:0> a["i"].length

=> 9

This is NOT an attack in YAML. Deleting.

NathanZook (talk) 16:54, 21 April 2021 (UTC)

NathanZook, the example you removed comes from one of the article's sources. A source that takes it seriously and treats it like a real problem.

Perhaps your inability to replicate it stems from the fact that, since then, some YAML projects have taken steps[1] to fix the problem?

If that's the case, I think it'd be better to avoid recentism and instead of removing examples, discuss what's been done to mitigate them. ApLundell (talk) 17:34, 21 April 2021 (UTC)

No, this is a matter of definition. YAML has always been designed to support pointers & recursive objects. That is why it is sometimes preferred over JSON. What this means is that it has always been a violation of the spec if an implementation created multiple copies of an object instead of using pointers. As mentioned elsewhere on this page, this is a vulnerability of macro expansion. YAML does not have macros, it has pointers.

NathanZook (talk) 20:08, 21 April 2021 (UTC)

Sources used in this article say that YAML is vulnerable to this attack. (Providing, as an example, code that I believe is functionally identical to the example code that was used here.)

I don't believe that using object pointers solves the issue anyway, it just kicks it down the road a little, as in order to do useful work with the parsed file, the value of a variable may need to be retrieved in its entirety. (Or iterated on.)

ApLundell (talk) 20:56, 21 April 2021 (UTC)

Googling for YAML and "Billion Laughs" shows that it's well known that YAML is vulnerable to this attack. So I've reverted and added an additional source. ApLundell (talk) 21:03, 21 April 2021 (UTC)

I'm sorry, but which sources? None of the listed articles mention YAML in their title.

Pointers does not "kick this problem down the road". If you have an object a, {"x": a} is fine in YAML. If your claim is correct, then it is not, because it "expands" to infinite space.

NathanZook (talk) 22:25, 21 April 2021 (UTC)

Okay. I found the reference. It appears that Go has this problem. I also notice that Go is NOT listed as supporting the Official YAML test suite.

I stand by my assertion that this document is only a problem with parsers that fail to properly support the YAML spec. As I'm currently unemployed, I have both the time & motivation to prove this.

NathanZook (talk) 22:36, 21 April 2021 (UTC)

Ok, but during your research remember that it's not just a question of whether it will fail during parsing. You also have to consider what will happen when the value is evaluated. Because that's part of the attack. You can't assume that it's happening to a value that's not being evaluated, because an attacker would choose one that will be. ApLundell (talk) 00:34, 22 April 2021 (UTC)

What happens depends on whether or not the parser is compliant. I have opened issues against go-yaml (https://github.com/go-yaml/yaml/issues/731, and https://github.com/go-yaml/yaml/issues/732). Ruby's is fine. Any parser which does not duplicate aliased nodes will be fine. This is specific to go-yaml, not YAML generally. I would be happy if the article called out that this is specific to that parser, rather than suggest that this affected anything else. NathanZook (talk) 04:48, 22 April 2021 (UTC)

Example code

Is the example code really needed? —Preceding unsigned comment added by 74.32.186.171 (talk) 04:30, 21 December 2010 (UTC)

Yes, the code brings much clarity to the subject for people who are able to comprehend it. --Lajm (talk) 14:21, 21 October 2012 (UTC)

Agreed, I found it very helpful. I don't work with XML much but when I read the code I immediately thought, "Oh, like a zip bomb". --24.87.152.127 (talk) 19:07, 20 February 2013 (UTC)

Agreed, it's clear, concise. Petermr (talk) 08:05, 3 May 2014 (UTC)

It's clear and concise but maybe it shouldn't be plagiarized from Microsoft? 206.172.186.206 (talk) 15:09, 12 September 2020 (UTC)

Copyright problem removed

Prior content in this article duplicated one or more previously published sources. The material was copied from: http://www.ibm.com/developerworks/xml/library/x-tipcfsx.html. Infringing material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. VernoWhitney (talk) 15:29, 22 April 2011 (UTC)

History

From memory I believe this exploit was first described on the [XML-DEV mailing list[2]] (I was list moderator) in 1997, thought it didn't use lol. IIRC it was described as a slightly esoteric potential problem rather than an exploit. If I have time I'll try to search the archives. I certainly think it merits a separate page. Petermr (talk) 08:03, 3 May 2014 (UTC)

Modern browser immunity

Firefox 29 seems to be immune. It expands lol1 to lol4 properly, but lol5 and higher do not produce more output (the result is the same as one iteration of lol4).

Occasionally the display fails with "XML Parsing Error: recursive entity reference". This can be relatively reliably reproduced by quickly refreshing the page a few times in a row.

XML Parsing Error: recursive entity reference

Location: file:///C:/Users/admin/Desktop/bil.xml

Line Number 15, Column 13:<lolz>&lol4;</lolz>

------------^

Internet Explorer 9 - same result, but on exceeding lol4 produces a totally blank page (no error).

Google Chrome (34.0.1847.131 m) - does not tolerate anything above lol2. Starting from lol3, it complains that the page has an "error on line 15 at column 13: Detected an entity reference loop"

These are the only ones I have installed and could test with. --HTMLCoder.exe / talk / stalk 18:44, 13 May 2014 (UTC)

This is good information, however, the bug does not just apply to browsers. A server may also load an XML file to do work such as parsing a file with an XSLT stylesheet... So we'd need to know which libraries are still affected and which have a feature that prevents the problem. Alexis Wilke (talk) 21:55, 15 October 2016 (UTC)

Quadratic?

Unless I am mistaken, the growth in the example expansion is exponential not quadratic. — Preceding unsigned comment added by Drtomconway (talk • contribs) 23:20, 30 May 2019 (UTC)

That's what it says: "The billion laughs attack described above takes an exponential amount of space." -- AnonMoos (talk) 18:37, 5 June 2019 (UTC)