[Python-modules-team] Bug#953013: Bug#953013: pyyaml: CVE-2020-1747: arbitrary command execution through python/object/new when FullLoader is used

[Scott Kitterman]

On Tuesday, March 3, 2020 11:41:26 AM EST Salvatore Bonaccorso wrote:
> Hi Scott,
> 
> On Tue, Mar 03, 2020 at 09:19:06AM -0500, Scott Kitterman wrote:
> > On Tuesday, March 3, 2020 2:29:51 AM EST Salvatore Bonaccorso wrote:
> > > Source: pyyaml
> > > Version: 5.3-1
> > > Severity: important
> > > Tags: security upstream
> > > Forwarded: https://github.com/yaml/pyyaml/pull/386
> > > 
> > > Hi,
> > > 
> > > The following vulnerability was published for pyyaml.
> > > 
> > > CVE-2020-1747[0]:
> > > |arbitrary command execution through python/object/new when FullLoader
> > > |is used
> > > 
> > > If you fix the vulnerability please also make sure to include the
> > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > > 
> > > For further information see:
> > > 
> > > [0] https://security-tracker.debian.org/tracker/CVE-2020-1747
> > > 
> > >     https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1747
> > > 
> > > [1] https://github.com/yaml/pyyaml/pull/386
> > > 
> > > Please adjust the affected versions in the BTS as needed.
> > 
> > Thank you for the report.
> > 
> > I've reviewed the current security-tracker entry and I believe it's
> > incorrect. While it's true that the unsafe loader was the default loader
> > in releases prior to 5.0, the safe loader has always been part of pyyaml
> > and recommended for cases where untrusted input needed to be parsed.
> > 
> > Although I haven't actually tried it yet, I reviewed the relevant code
> > from
> > the earlier releases and I believe the same fix would work.  Unfortunately
> > I don't have a test case to verify that.
> > 
> > Also, the upstream pull request to fix this is incomplete.  It only
> > provides a fix for python3-yaml, not python-yaml.
> > 
> > I've updated the affected versions in the BTS and will take a shot at
> > updating the security tracker shortly.
> 
> I'm actually unsure how to handle that CVE. While I believe to
> undrstand that the unsafe loader are present, my understanding of the
> CVE-2020-1747 is directly associated with the FullLoader use and
> looking at the Red Hat bug where the CVE originates,
> https://bugzilla.redhat.com/show_bug.cgi?id=1807367 it looks to me
> that the CVE's scope is only to cover FullLoader.
> 
> Again I'm not really sure. But if that interpretation would be
> correct, and given upstream recommended for for cases where untrusted
> input needed to be parsed to use the safe loaders, then not-affected
> would theoretically be correct, but maybe with changed/expanded
> explanation on that FullLoader is not present until 5.1.
> 
> I'm not going to touch the CVE entry in the security-tracker now, and
> looking for feedback from you all (you, Emilio, Moritz said to look as
> well a the CVE later).

OK.  If anyone has a reproducer for this, it'd be very helpful to sort it out.

I think this is like the recent CVE for python-bleach where the affected code 
didn't exist in the older releases, but the issue was still demonstrable.  I 
suspect that pyyaml << 5.1 will still have this problem even with the 
SafeLoader, since the FullLoader shares code with the older SafeLoader.

I can see how to adapt the upstream pull request to the 3.X releases, but I 
agree it's not clear what the regression risk would be.  I decided to leave 
the security tracker alone for now too.

Scott K
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/python-modules-team/attachments/20200303/6d5ad957/attachment-0001.sig>