Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate yaml.load and add FullLoader and UnsafeLoader classes #257

Closed
wants to merge 2 commits into from

Conversation

@ingydotnet
Copy link
Member

@ingydotnet ingydotnet commented Feb 23, 2019

This addresses CVE-2017-18342

YAML is cross-programming language serialization language. YAML happens to be
used quite often as a configuration format. PyYAML is an implementation of YAML
that provides human friendly (plain text) data serialization for Python.

The CVE asserts that yaml.load() can execute arbitrary code. This is true.
Here are some trivial examples:

python -c 'import yaml; yaml.load("!!python/object/new:os.system [echo EXPLOIT!]")'`
python -c 'import yaml; print(yaml.load("!!python/object/new:abs [-5]"))'
python -c 'import yaml; yaml.load("!!python/object/new:eval [exit(5)]")' ; echo $?
python -c 'import yaml; yaml.load("!!python/object/new:exit [5]")' ; echo $?

This PR prevents arbitrary code execution for yaml_load().

YAML has always had a safe_load method that can load a subset of YAML
without the risk of code execution. CVE-2017-18342 seems to suggest that load
should call safe_load by default. This is not feasible, because it will break
code that is using PyYAML as a full serialization language, not just for simple
config.

Since PyYAML was created as serialization module for Python, it was heavily
influenced by Python's primary (but not human readable) serialization
format/module, Pickle. Pickle has the same problems of code execution on
untrusted data, yet there isn't a similar CVE for Pickle.

The PyYAML maintainers have decided that the plain usage of yaml.load() has
to be deprecated. We can't make it call safe_load and it is unsafe by
default. Even though it has been loudly documented as being unsafe from the
very beginning (just like Pickle), the Python community is raising red flags.


Here is how things will work in 5.1:

yaml.load() will issue a warning unless you call it with the Loader=
parameter. The available Loaders are:

  • BaseLoader
  • FullLoader
  • SafeLoader
  • UnsafeLoader
  • Loader (old name for UnsafeLoader)

You can also use the sugar methods:

  • full_load() -- for load(..., Loader=FullLoader)
  • safe_load()
  • unsafe_load()

There are methods to disable the warning when you use modules that use
yaml.load() that you can't change.

The end result is that you need to declare which Loader you want to use.


We added a new loader class called FullLoader, and we made it the default for
load(). This class is almost as complete for serialization as
UnsafeLoader/Loader, but it avoids arbitrary code execution. We don't expect it
will break any code in the wild.

We still recommend that people choose SafeLoader for untrusted data, but
aribitrary code execution will no longer be possible using yaml.load() with
the default loader (FullLoader). FullLoader will instantiate objects of classes
that you have imported. Since object instantiation runs the class's constructor
code, that may be exploitable.

In a future release (after 5.1) yaml.load() will raise an exception if you don't
explicitly choose the Loader to use.

@ingydotnet ingydotnet added this to To Do in 5.1 Release Feb 23, 2019
@ingydotnet ingydotnet moved this from Possible PRs and To Do items to Added to release/5/1 branch in 5.1 Release Feb 23, 2019
@ingydotnet ingydotnet force-pushed the maintainers/load-deprecation branch from b48390a to 3cca84b Feb 26, 2019
@ingydotnet
Copy link
Member Author

@ingydotnet ingydotnet commented Feb 28, 2019

The warning issued by load() contains this url: https://msg.pyyaml.org/load
Which has full current details about the warning and how to respond to it.

Loading

ingydotnet and others added 2 commits Mar 8, 2019
The `load` and `load_all` methods will issue a warning when they are
called without the 'Loader=' parameter. The warning will point to a URL
that is always up to date with the latest information on the usage of
`load`.

There are several ways to stop the warning:

* Use `full_load(input)` - sugar for `yaml.load(input, FullLoader)`
  * FullLoader is the new safe but complete loader class
* Use `safe_load(input)` - sugar for `yaml.load(input, SafeLoader)`
  * Make sure your input YAML consists of the 'safe' subset
* Use `unsafe_load(input)` - sugar for `yaml.load(input, UnsafeLoader)`
  * Make sure your input YAML consists of the 'safe' subset
* Use `yaml.load(input, Loader=yaml.<loader>)`
  * Or shorter `yaml.load(input, yaml.<loader>)`
  * Where '<loader>' can be:
    * FullLoader - safe, complete Python YAML loading
    * SafeLoader - safe, partial Python YAML loading
    * UnsafeLoader - more explicit name for the old, unsafe 'Loader' class
* yaml.warnings({'YAMLLoadWarning': False})
  * Use this when you use third party modules that use `yaml.load(input)`
  * Only do this if input is trusted

The above `load()` expressions all have `load_all()` counterparts.

You can get the original unsafe behavior with:
* `yaml.unsafe_load(input)`
* `yaml.load(input, Loader=yaml.UnsafeLoader)`

In a future release, `yaml.load(input)` will raise an exception.

The new loader called FullLoader is almost entirely complete as
Loader/UnsafeLoader but it does it avoids all known code execution
paths. It is the preferred YAML loader, and the current default for
`yaml.load(input)` when you get the warning.

Here are some of the exploits that can be triggered with UnsafeLoader
but not with FullLoader:
```
python -c 'import os, yaml; yaml.full_load("!!python/object/new:os.system [echo EXPLOIT!]")'`
python -c 'import yaml; print yaml.full_load("!!python/object/new:abs [-5]")'
python -c 'import yaml; yaml.full_load("!!python/object/new:eval [exit(5)]")' ; echo $?
python -c 'import yaml; yaml.full_load("!!python/object/new:exit [5]")' ; echo $?
@ingydotnet ingydotnet force-pushed the maintainers/load-deprecation branch from 8de78b6 to 2869cea Mar 8, 2019
@perlpunk
Copy link
Member

@perlpunk perlpunk commented Mar 14, 2019

Merged in 0cedb2a and 857dff1

Loading

@perlpunk perlpunk closed this Mar 14, 2019
fblackburn1 added a commit to wazo-platform/wazo-auth that referenced this issue Apr 16, 2019
reason: with pyyaml >= 5, the load function without Loader is deprecated.
Even if we do not use version 5 for now, we should use good practices.
https://pyyaml.org/wiki/PyYAMLDocumentation#loading-yaml
yaml/pyyaml#257
fblackburn1 added a commit to wazo-platform/wazo-auth-keys that referenced this issue Apr 16, 2019
reason: with pyyaml >= 5, the load function without Loader is deprecated.
Even if we do not use version 5 for now, we should use good practices.
https://pyyaml.org/wiki/PyYAMLDocumentation#loading-yaml
yaml/pyyaml#257
fblackburn1 added a commit to wazo-platform/wazo-confd that referenced this issue Apr 16, 2019
reason: with pyyaml >= 5, the load function without Loader is deprecated.
Even if we do not use version 5 for now, we should use good practices.
https://pyyaml.org/wiki/PyYAMLDocumentation#loading-yaml
yaml/pyyaml#257
fblackburn1 added a commit to wazo-platform/wazo-confgend that referenced this issue Apr 16, 2019
reason: with pyyaml >= 5, the load function without Loader is deprecated.
Even if we do not use version 5 for now, we should use good practices.
https://pyyaml.org/wiki/PyYAMLDocumentation#loading-yaml
yaml/pyyaml#257
fblackburn1 added a commit to wazo-platform/wazo-dird that referenced this issue Apr 16, 2019
reason: with pyyaml >= 5, the load function without Loader is deprecated.
Even if we do not use version 5 for now, we should use good practices.
https://pyyaml.org/wiki/PyYAMLDocumentation#loading-yaml
yaml/pyyaml#257
fblackburn1 added a commit to wazo-platform/wazo-plugind that referenced this issue Apr 16, 2019
reason: with pyyaml >= 5, the load function without Loader is deprecated.
Even if we do not use version 5 for now, we should use good practices.
https://pyyaml.org/wiki/PyYAMLDocumentation#loading-yaml
yaml/pyyaml#257
@perlpunk perlpunk deleted the maintainers/load-deprecation branch Dec 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
5.1 Release
Added to release/5/1 branch
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants