Allow configuration for preventing billion laughs attack

Issue #377 resolved
Former user created an issue

What steps will reproduce the problem?

Currently parser will always evaluate Aliases present in YAML documents. Malicious payload such as [1] could be used to perform an DOS attack against application that are internally using SnakeYaml (this payload will result in heap overflow).

[1] https://en.wikipedia.org/wiki/Billion_laughs#Variations

What is the expected output? What do you see instead?

It is expected that there would be a configuration, usable to turn off Alias support altogether, or to define the maximum depth parser should resolve dependencies before throwing an exception.

What version of SnakeYAML are you using? What is the Java version? v1.18

Test logic usable to reproduce the behaviour

        String data = "a: &a [\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\"]\n" +
                "b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]\n" +
                "c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]\n" +
                "d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]\n" +
                "e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]\n" +
                "f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]\n" +
                "g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]\n" +
                "h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]\n" +
                "i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]";
        Yaml yaml = new Yaml();
        Map map = (Map) yaml.load(data);

How XML parsers address same issue*

Check [2] dbf.setExpandEntityReferences(false);

[2] https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#JAXP_DocumentBuilderFactory.2C_SAXParserFactory_and_DOM4J

Thank you!

Comments (20)

  1. Andrey Somov repo owner

    This has already been reported billion times during last few years. Please do not approach developers by sending e-mails.

    Please add your comments ONLY if you wish to contribute or you have a proposal.

  2. Colm O hEigeartaigh

    @Andrey Somov Is there a way of doing the same for SnakeYaml 1.x? Or are users forced to upgrade to the Snakeyaml Engine to avoid this attack?

  3. Andrey Somov repo owner

    Than you can use exactly the same way as you use to prevent the endless data (when the same attacker never closes the input stream).

    Or you can implement your own filter to exclude invalid content (counting * and & for instance)

    Please be aware that the report will still complain (do you use OWASP ?)

  4. Colm O hEigeartaigh

    Hi Andrey,

    I don’t understand why a user should have to implement their own filter to prevent a denial of service attack. For XXE we can just disable entity expansion via the DocumentBuilderFactory - it would not be reasonable to expect users of the API to try to prevent this type of attack in some custom way. Another example would be Woodstox which projects I work on (Apache CXF) uses to parse XML - it allows you to configure various things like total number of elements, nested elements, etc to prevent denial of service attacks. Is there a technical reason why it’s not possible to port the same type of change implemented in the Snakeyaml engine to the 1.x releases? Or even some simplified version which disables aliases altogether?

  5. Andrey Somov repo owner

    I don’t understand why

    Please help me to explain it, providing your solution for the problem when the attacker does not close the input stream.

  6. Zoran Regvart

    @Andrey Somov you might not be aware of this, your comment is a whataboutism. This is not constructive with the subject at hand. Snakeyaml is widely used library and denial service attacks such as billion laughs are serious threats to the availability to the library user’s systems. Can we, please, focus the discussion on this topic?

  7. Andrey Somov repo owner

    @Zoran Regvart: please be aware that your comment is very insulting.

    1.You add links to external resources without any reason

    2. You propose nothing

    3. You demand without any suggestion to help

    4. You use open source and you do not begin with a “thank you“ for those who invested years to make it work.

    Can you please show your way how you solve the problem with never ending stream ? If we have the solution we can copy it for this million attack.

  8. Colm O hEigeartaigh

    @Andrey Somov Would you consider accepting a patch that adds a configuration switch to just disable alias expansion altogether?

  9. Andrey Somov repo owner
    1. as far as I understand you can ignore my questions, but you expect that I do not ignore yours
    2. this is open source - you do not need a permission to contribute

  10. Nicole Gru

    Hi @Andrey Somov ,

    Could you tell me if any other versions besides 1.18 are vulnerable ? as seen by NVD they only mark 1.18 but from a previous thread (#471) they claim all versions below 1.25 also vulnerable

    Thank you in advance !

  11. Log in to comment