Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 682964 (unsafe-pyyaml) - [TRACKER] packages calling dev-python/pyyaml in an insecure manner
Summary: [TRACKER] packages calling dev-python/pyyaml in an insecure manner
Status: CONFIRMED
Alias: unsafe-pyyaml
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Python Gentoo Team
URL:
Whiteboard:
Keywords:
Depends on: 698668 682922 683814 685754 686818
Blocks: 687292
  Show dependency tree
 
Reported: 2019-04-09 17:58 UTC by Virgil Dupras
Modified: 2019-10-27 16:14 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Virgil Dupras gentoo-dev 2019-04-09 17:58:56 UTC
If you get "RuntimeError: Unsafe load() call disabled by Gentoo", it means that you're running a program that uses pyyaml in an insecure manner, that is, that calls load() directly. Complete details in upstream issue 265 [1] and bug 659348.

As a maintainer of that program's package, what can you do about it? This:

1. In all stable ebuilds, add a "<5" version constraint on the pyyaml dep. This will fix the immediate break. However, we need to get rid of these constraints soon, so we go to step 2.

2. Look at upstream's change log and see if a recent change related to pyyaml 5 was made. If yes, then you can probably remove the "<5" constraint for those versions.

3. If not, you'll need to patch out those unsafe calls. Look for calls to "yaml.load()" and replace them with calls to "yaml.safe_load()" or "yaml.full_load()" (see below for details).

4. Proceed to stabilization of ebuilds without "<5" constraints so we can purge unsafe ebuilds from the tree.

safe_load() or full_load()?

The core of the security problem here is that pyyaml has the ability to serialize and de-serialize arbitrary python objects. However, this means arbitrary code execution. This means that as soon as not all loaded yaml streams are from trusted sources, using pyyaml.load() is a wide open security hole.

safe_load() doesn't support arbitrary python object serialization. Using this closes the hole. However, some programs need this feature to work properly. If you're not sure what to do, using safe_load() is the best option, but be prepared for the possibility of new bugs arising: if the program relies on arbitrary python serialization, it won't properly work.

If you know for sure that the program never loads yaml streams from untrusted sources, the easiest way to proceed is to use full_load(). Be aware, however, that if the program loads a stream from an untrusted source, you're introducing a security hole by using full_load() (but not as bad as the old load() one. see upstream issue for details).

If the program needs arbitrary python object serialization *and* loads yaml from untrusted sources, it has a big security problem and you might want to consider masking it and take the issue upstream.

[1]: https://github.com/yaml/pyyaml/issues/265