> loading an untrusted yaml document is generally unsafe,
TIL and this is... Not great?
I often parse JSON as YAML. Since YAML is a superset of JSON, all valid JSON files parse as a valid YAML file too, but now you can add comments to your JSON since YAML has comments. Didn't know I was opening my process up to code execution doing this...
Knowing this, YAML is dead to me as a format. This really seems unacceptable for a markup parser.
Pretty much all parsers have some way to "safely" parse a YAML document which disables the custom-object unmarshal stuff; sometimes this is the default, sometimes not, some libraries/languages don't support this at all in the first place.
If it's enabled, then it's trivial to exploit; e.g. in Python:
!!python/object/apply:os.system
args: ['ls /']
If you parse this with "yaml.load()" in PyYAML (which, I believe, is the most commonly used YAML library for Python) then it will execute that code. You will need to use "yaml.safe_load()".
I believe the situation in Ruby is similar, and in PHP the only way to get any safe sane behaviour is to modify a php.ini setting (which at least defaults to "off" now, but there is no way to know if a line is safe just by looking at the code).
In Go this entire feature isn't supported at all AFAIK, so it's always safe.
Not sure about other languages from the top of my head.
I'm not sure it's true that parsing an untrusted YAML document is generally unsafe. That has to be a property of the parser, not the format.
As TFA says:
> In Python, you can avoid this pitfall by using yaml.safe_load instead of yaml.load
In Ruby, there are now analogous options (including - of course lol - a gem which monkeypatches the YAML module to make it safe by default) [1]:
> Use the safe-yaml gem which overrides YAML.load
> Require a newer version of Psych that provides a safe-load option
In Java, SnakeYaml has a document about security which i think is a long way of admitting that it's not secure [2]. It looks like eo-yaml just doesn't support tags at all.
To be fair, YAML itself does not specify how tags should be interpreted, technically the idea of grabbing constructors from those is the library's issue. But then again, you wouldn't want to accidentally introduce code execution when you adopt a new library/language.
TIL and this is... Not great?
I often parse JSON as YAML. Since YAML is a superset of JSON, all valid JSON files parse as a valid YAML file too, but now you can add comments to your JSON since YAML has comments. Didn't know I was opening my process up to code execution doing this...
Knowing this, YAML is dead to me as a format. This really seems unacceptable for a markup parser.