Problem

There is a number of vulnerability reports related to SnakeYAML in the NIST database.

Most of them we consider as minor as long as you trust the source of the YAML you are feeding to SnakeYAML.

When you are a Spring user, you may have a look here.

Explanation

Safe:

• SnakeYAML does not open any sockets to receive any data (it must be explicitly fed with data from the provided InputStream)
• SnakeYAML does not go to any external resource via HTTP or TCP (or anything else)
• It is safe to parse your configuration files (in Spring Boot or any other)
• It is safe to parse the data provided from external resource if they do not DELIBERATELY want to do any harm (for instance to send a huge YAML and wait for your computer to die when the memory is exhausted)

Dangerous:

• It is unsafe to open a socket and blindly forward any trash as input for the parser.

There was never any real use case reported for the dangerous scenario (feel free to share!). But it is always possible to first read the input and do some preliminary checks (size, keywords, etc) before feeding the parser. (Sanitize and validate the inputs before it goes into SnakeYAML)

Conclusion

You know the data you are parsing with SnakeYAML.

If you are dealing with the YAML files received from untrusted sources - check those Vulnerabilities and assess the risks.

When you plan to feed the parser with untrusted data, please study the settings which allow to restrict incoming data.

Impact

We consider those as low priority issues. Which we may fix at some point. PRs are very much appreciated !

Please be aware that the issue tracker of DependencyCheck is overloaded with bugs over false positives.

Clarification

Nothing explains better than an example. Here is one.

Use case: a man with a gun (with translation to CVE)

1. The security authority decided that "a man with a gun" is potentially dangerous. Of course not every man is dangerous but if you see a man with a gun approaching you - be on alert.

Translation: NIST announced that SnakeYAML under very special conditions (which are NEVER reported to the SnakeYAML maintainers) may cause issues.

2. The cameras on the street (because of the very low quality of the software) cannot distinguish a man with or without a gun. So they decided to alert for every man.

Translation: Low quality tooling (OWASP, Meld, Snyk etc) because they cannot recognise the usage of SnakeYAML, they simply put an alert for every usage.

3. The shops instead of trying to understand and ignore the issue, they close the doors for all the men.

Translation: instead of raising issues with the low quality tooling, developers come to SnakeYAML.

Please come to your tool and raise an issue with them. Please not not accept an excuse that it is CVE and NIST. It is not. In NIST they mention a very important condition which is never checked by the tool, producing yet another false positive.

Solution

No dependency

When you do not have SnakeYAML in your direct dependencies and you do not have to do anything. It is a false positive and you can ignore it (preferable creating an issue for the low quality tool which created this false positive)

When you use Spring, they already did a lot of precautions. Even when you do not use Spring but other tool (like H2), it is still safe if you provide the configuration yourself.

The only exception is that you give untrusted users to provide any YAML file. This case is covered below (even though it was never reported - please drop us a line if you think you fall into this category).

SnakeYAML is a direct dependency

It means you directly create configuration form YAML and the data may come either trusted or from untrusted users.

TODO...

Data from untrusted source

1. Sanitize
2. Use SafeConstructor if possible (or migrate to SnakeYAML Engine)
3. Restrict data input by limiting size, anchors, ect

TODO ...