Bug 23242 - python-yaml new security issue CVE-2017-18342
Summary: python-yaml new security issue CVE-2017-18342
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA6-64-OK MGA6-32-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2018-06-27 14:27 CEST by David Walser
Modified: 2019-04-05 20:14 CEST (History)
7 users (show)

See Also:
Source RPM: python-yaml-3.10-13.mga6.src.rpm
Status comment: Fixed upstream in 5.1

Loading and printing an instance of a class converted to YAML format (438 bytes, text/plain)
2019-04-01 19:51 CEST, Len Lawrence
Series of tests from online tutorial (2.85 KB, text/plain)
2019-04-01 20:41 CEST, Len Lawrence

Description David Walser 2018-06-27 14:27:00 CEST
A CVE has been assigned:

for an issue in PyYAML described here:

The issue was fixed by an API change in 4.1.  It's not clear what the expected backportable fix would look like.
Comment 1 Marja Van Waes 2018-06-28 09:13:01 CEST
Assigning to the Python stack maintainer, CC'ing the registered maintainer.

Assignee: bugsquad => python
CC: (none) => makowski.mageia, marja11

Comment 2 Bruno Cornec 2018-10-11 01:08:17 CEST
I proposed a 4.1 version in cauldron. It would be great that more savy python packagers look at it and check it doesn't break compatibility. Seems the only end packages using it are crmsh and unknown-horizons

CC: (none) => bruno

David Walser 2018-10-12 00:57:38 CEST

Source RPM: python-yaml-3.12-2.mga7.src.rpm => python-yaml-3.10-13.mga6.src.rpm
Version: Cauldron => 6

Comment 3 David Walser 2019-03-30 18:51:59 CET
Fixed again upstream in 5.1, Fedora advisory from March 29:

We should upgrade it again, as 4.1 was pulled by upstream for causing problems.

Status comment: (none) => Fixed upstream in 5.1
Version: 6 => Cauldron
Whiteboard: (none) => MGA6TOO
Severity: normal => major

Comment 4 Bruno Cornec 2019-04-01 00:39:30 CEST
cauldron updated with 5.1
What is the recommendation for mga6 ? It wasn't update with 4.1.

Version: Cauldron => 6
Whiteboard: MGA6TOO => (none)

Comment 5 David Walser 2019-04-01 00:41:29 CEST
It sounds like the API changes made 4.1 unsafe but 5.1 should be safer.  As long as it doesn't break anything that uses it, we can update it.  It sounds like it'll be OK.
Comment 6 Bruno Cornec 2019-04-01 01:01:24 CEST
5.1 Update pushed for mga6 as well then.

Assignee: python => qa-bugs

Comment 7 David Walser 2019-04-01 01:35:15 CEST
Bruno, you incorrectly added a subrel (never do that when updating to a new version), so now you need to rebuild in Cauldron.


Updated python-yaml package fixes security vulnerability:

It was found that using yaml.load() API on untrusted input could lead to
arbitrary code execution (CVE-2017-18342).


Updated packages in core/updates_testing:

from python-yaml-5.1-1.1.mga6.src.rpm
Comment 8 Bruno Cornec 2019-04-01 01:54:28 CEST
Sorry, I'm always hesitating wtr subrel when the release is the same :-( Will update cauldron immediately.
Comment 9 Len Lawrence 2019-04-01 19:51:55 CEST
Created attachment 10897 [details]
Loading and printing an instance of a class converted to YAML format

Should work with python and python3.

CC: (none) => tarazed25

Comment 10 Len Lawrence 2019-04-01 20:41:54 CEST
Created attachment 10898 [details]
Series of tests from online tutorial

To be run with python and python3.
The failure in the last test needs to be explained before the packages can be moved on.
Comment 11 Len Lawrence 2019-04-01 20:42:31 CEST
mga6, x86_64

Nothing useful found for CVE-2017-18342

UPDATED the two packages.
A big jump, from 3.10-13.

Found a tutorial at https://pyyaml.org/wiki/PyYAMLDocumentation.
Several of the example snippets failed and I could not get in-string encoding
declarations to work.  In particular a document string containing several documents, specified by a name: key, throws this error, e.g.:
yaml.scanner.ScannerError: mapping values are not allowed here
  in "<string>", line 3, column 9:
        name: The Set of Gauntlets 'Pauraegen'
Using the load function is flagged as unsafe so switching to safe_load is recommended,
otherwise the loader needs to be specified, but how?  (See later)

With safe_load:
$ python tutorial2.py
['Hesperiidae', 'Papilionidae', 'Apatelodidae', 'Epiplemidae']
{'none': [None, None], 'bool': [True, False, True, False], 'int': 42, 'dict': {'hp': 13, 'sp': 5}, 'float': 3.14159, 'list': ['LITE', 'RES_ACID', 'SUS_DEXT']}

I could not get in-string encoding declarations to work either, possibly because of uncertainty about syntax.

$ cat tutorial3.py
import yaml

class Hero:
        def __init__(self, name, hp, sp):
            self.name = name
            self.hp = hp
            self.sp = sp
        def __repr__(self):
            return "%s(name=%r, hp=%r, sp=%r)" % (
                self.__class__.__name__, self.name, self.hp, self.sp)

objecttest = yaml.load("""
    name: Welthyr Syxgon
    hp: 1200
    sp: 0

print objecttest

$ python tutorial3.py
tutorial3.py:17: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
Hero(name='Welthyr Syxgon', hp=1200, sp=0)

In that test I had to revert to load because with safe_load the example failed.
At a guess, the unsafe loader had caused  problems with the retrieval of the object for
printing which might have been overcome by a Loader= declaration somewhere in the
script.  Don't know how to do that.  Maybe a python expert could advise?
The link suggested states that safe_load handles only a subset of YAML, which explains the failures seen here.
Further reading:
yaml.load(input, Loader=yaml.FullLoader) loads the full YAML language.
The FullLoader cannot be enabled by default because that would annul the safety policy.

Backtracking and editing the scripts:

Several of the examples from the online tutorial have been condensed into the attached
script, yamltests.py.  Just run
$ python yamltests.py
to view the results.  yaml3tests.py should work with python3 also.
Note the failure in the last test.
Running interactive python with the same input as the tutorial shows for the Monster
class raises the same error that the script test produces, namely "mapping values are
not allowed here" which comes from yaml.scanner.

I have very little knowledge of python so cannot interpret this.  Appealing toexperts to
examine the syntax.  Otherwise the conclusion is that the package is broken.
Comment 12 David Walser 2019-04-01 21:41:28 CEST
Probably the most useful way to test this is through other packages that require it.
Comment 13 Len Lawrence 2019-04-01 22:32:45 CEST
Yes, I guess I should do that, but it would still be reassuring to see an explanation of the error.

Have to wait until tomorrow now.  been working on this all day, literally.
Comment 14 Len Lawrence 2019-04-01 23:32:52 CEST
Several applications use these packages including ansible and rednotebook.
Chose to install and test rednotebook under strace.  Created a diary and wrote the first page.  The trace showed many opens for python yaml related libraries and operations including loading and serializing.  That seems to demonstrate that python-yaml is being used successfully.
Comment 15 Len Lawrence 2019-04-02 09:50:16 CEST
Passing this for 64-bits but shall probably raise a bug on the failure of the tutorial example.

Whiteboard: (none) => MGA6-64-OK

Comment 16 Thomas Andrews 2019-04-02 21:51:53 CEST
Tested in 32-bit for installation issues only. Looks OK. Validating. Suggested advisory in Comment 7.

Whiteboard: MGA6-64-OK => MGA6-64-OK MGA6-32-OK
Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

Dave Hodgins 2019-04-04 15:09:03 CEST

CC: (none) => davidwhodgins
Keywords: (none) => advisory

Comment 17 Mageia Robot 2019-04-05 20:14:13 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.