Debian Bug report logs - #862373
libyaml-libyaml-perl: Unconditionally instantiates objects from yaml data

Display info messages

Message #3 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jakub Wilk <jwilk@jwilk.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: lintian: insecure YAML validation

Date: Sat, 6 May 2017 13:01:50 +0200

[Message part 1 (text/plain, inline)]

Package: lintian
Version: 2.5.41
Tags: security

Lintian uses the YAML::XS module to validate YAML in debian/upstream/metadata.
This module is happy to deserialize objects of any existing Perl class. For 
Lintian, the File::Temp::Dir class can be abused to remove arbitrary directory 
trees. (There might be other exciting ways to exploit this bug, but I'm too 
lazy to investigate further.)

I've attached proof-of-concept exploit:

$ mkdir /tmp/moo
$ ls -d /tmp/moo
/tmp/moo
$ lintian -C upstream-metadata badyaml_1.dsc
$ ls -d /tmp/moo
/bin/ls: cannot access '/tmp/moo': No such file or directory

-- 
Jakub Wilk

[badyaml_1.tar.xz (application/x-xz, attachment)]

[badyaml_1.dsc (text/plain, attachment)]

Message #12 received at 861958@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: Jakub Wilk <jwilk@jwilk.net>, 861958@bugs.debian.org

Subject: Re: Bug#861958: lintian: insecure YAML validation

Date: Sat, 06 May 2017 19:29:46 +0200

On samedi 6 mai 2017 13:01:50 CEST you wrote:
> Lintian uses the YAML::XS module to validate YAML in
> debian/upstream/metadata.

Unless debian/upstream/metadata needs fancy YAML format (e.g. anchor alias 
tags ...), the easiest way out it to use YAML::Tiny instead of YAML::XS. This 
should be a drop-in replacement.

> This module is happy to deserialize objects of any existing Perl class. For
> Lintian, the File::Temp::Dir class can be abused to remove arbitrary
> directory trees. (There might be other exciting ways to exploit this bug,
> but I'm too lazy to investigate further.)

I wonder if this behavior should be considered as a YAML bug...

All the best
-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
    http://ddumont.wordpress.com/        -o-   irc: dod at irc.debian.org

Message #19 received at 861958@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: 861958@bugs.debian.org

Subject: Re: lintian: insecure YAML validation [CVE-2017-8829]

Date: Wed, 10 May 2017 19:00:53 +0200

Ive logged a bug to upstream YAML parser library:

https://github.com/ingydotnet/yaml-pm/issues/176

HTH

Message #24 received at 861958@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: dod@debian.org, 861958@bugs.debian.org

Subject: Re: Bug#861958: lintian: insecure YAML validation [CVE-2017-8829]

Date: Wed, 10 May 2017 18:41:00 +0000

Dominique Dumont:
> Ive logged a bug to upstream YAML parser library:
> 
> https://github.com/ingydotnet/yaml-pm/issues/176
> 
> HTH
> 

Thanks. :)

~Niels

Message #29 received at 861958@bugs.debian.org (full text, mbox, reply):

From: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>

To: Dominique Dumont <dod@debian.org>

Cc: 861958@bugs.debian.org

Subject: Re: Bug#861958: lintian: insecure YAML validation

Date: Thu, 11 May 2017 23:51:25 +0200

[Message part 1 (text/plain, inline)]

clone 861958 -1
reassign -1 libyaml-libyaml-perl
retitle -1 libyaml-libyaml-perl: Unconditionally instantiates objects from yaml data
thanks

Dominique Dumont wrote...

> On samedi 6 mai 2017 13:01:50 CEST you wrote:

> > This module is happy to deserialize objects of any existing Perl class. For
> > Lintian, the File::Temp::Dir class can be abused to remove arbitrary
> > directory trees. (There might be other exciting ways to exploit this bug,
> > but I'm too lazy to investigate further.)
> 
> I wonder if this behavior should be considered as a YAML bug...

At least I consider the unconditional instantiation of object a bug,
hence cloning.

As previously mentioned in debian-perl@, there is no easy solution,
assuming some code out there intentionally uses that feature, and in
a safe matter. If we choose to ignore that, at least for the time being,
we can disable the blessing entirely by dropping the three sv_bless
invocations in <LibYAML/perl_libyaml.c>. This makes the attached
reproducer pass.

Before releasing that change however, there should be an audit of all
the roughly 40 packages in Debian that use YAML::XS to avoid unintended
breakage. In the worst case, that simple approach isn't feasible and
the instantiation needs to be made configurable - something that
requires coordination with upstream[1] and/or other distributions.

We should discuss this during the sprint.

    Christoph

[1] But see https://github.com/perl11/cperl/issues/198

[reprod (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #44 received at 862373@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: 862373@bugs.debian.org

Subject: Re: Unconditionally instantiates objects from yaml data

Date: Fri, 12 May 2017 08:03:12 +0200

> As previously mentioned in debian-perl@, there is no easy solution,

A possibility to limit the impact is to deny object creation if the class has 
a DESTROY method.

Knowing that UNIVERSAL has no DESTROY method, It's fairly easy to test:

$ perl -MFile::Temp -E 'say File::Temp->can("DESTROY") ? "yes" : "no";'
yes
$ perl -E 'say UNIVERSAL->can("DESTROY") ? "yes" : "no";'
no
$ perl -MGetopt::Long -E 'say Getopt::Long->can("DESTROY") ? "yes" : "no";'
no

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Message #49 received at 862373@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: 862373@bugs.debian.org

Cc: debian-perl@lists.debian.org

Subject: Re: Unconditionally instantiates objects from yaml data

Date: Sat, 11 Nov 2017 17:17:28 +0100

On Fri, 12 May 2017 08:03:12 +0200 Dominique Dumont <dod@debian.org> wrote:
> > As previously mentioned in debian-perl@, there is no easy solution,

I've prepared a patch to provide a SafeLoad method. This avoids breaking 
application that need to create Perl class from YAML.

On the downside:
- application using YAML may need to be updated
- there's no similar method (yet ?) in other YAML implementations.

This is not an ideal solution, but is better than nothing...

Thoughts ?

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Message #54 received at 862373@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: debian-perl@lists.debian.org

Cc: 862373@bugs.debian.org

Subject: Re: Unconditionally instantiates objects from yaml data

Date: Sat, 11 Nov 2017 18:41:41 +0100

On Saturday, 11 November 2017 17:17:28 CET Dominique Dumont wrote:
> This is not an ideal solution, but is better than nothing...

Got good reasons [1], upstream is not thrilled about the idea of adding
SafeLoad to YAML::XS API. So I've disabled the patch.

TINITA suggests [2] to use unbless from Data::Structure::Util to sanitize a data 
structure coming from untrusted source. 

This solution is probably easier than replacing YAML::XS with YAML::TIny (which is 
not always possible and behave differently with utf8)

All the best

[1] https://github.com/ingydotnet/yaml-libyaml-pm/issues/45#issuecomment-343678829
[2] https://github.com/ingydotnet/yaml-libyaml-pm/issues/45#issuecomment-343679429
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Message #59 received at 862373@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: 862373@bugs.debian.org

Cc: debian-perl@lists.debian.org

Subject: solved upstream: Unconditionally instantiates objects from yaml data

Date: Wed, 10 Jan 2018 17:29:18 +0100

Hi

Good news: object creation can now be disabled starting from  YAML::XS 0.69.

That said, the default behavior is unchanged (which is reasonable).

This means that any application loading untrusted YAML data must be modified 
to set $YAML::XS::LoadBlessed to 0 before loading YAML files.

I guess this applies to lintian. (I'll check what's required for cme).

All the best
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Message #66 received at 862373@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: 862373@bugs.debian.org

Cc: debian-perl@lists.debian.org

Subject: Re: solved upstream: Unconditionally instantiates objects from yaml data

Date: Tue, 27 Feb 2018 11:59:26 +0100

TINITA explains in this post how safely use YAML in Perl:

http://blogs.perl.org/users/tinita/2018/02/safely-load-untrusted-yaml-in-perl.html

HTH

Message #73 received at 862373@bugs.debian.org (full text, mbox, reply):

From: gregor herrmann <gregoa@debian.org>

To: 862373@bugs.debian.org, 862475@bugs.debian.org

Subject: The State of the YAML

Date: Fri, 18 May 2018 11:09:23 +0200

[Message part 1 (text/plain, inline)]

Quick status update on the perl YAML modules and the problem of
instantiating objects:

* libyaml-syck-perl has $YAML::LoadBlessed since a long time
* libyaml-libyaml-perl since 0.69 and libyaml-perl since 1.25 have
  added $YAML::LoadBlessed as well
* all three by default set it to 1 

(and YAML::Tiny is not affected as far as I know)

So I guess we have to consider if we're happy with the ability to
turn off loading objects and recommend it to consumers and close the
bugs; or if we want to change the defaults, which means setting
$YAML::LoadBlessed to 0 in all three packages.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   

[signature.asc (application/pgp-signature, inline)]

Message #76 received at 862373@bugs.debian.org (full text, mbox, reply):

From: Damyan Ivanov <dmn@debian.org>

To: 862475@bugs.debian.org

Cc: 862373@bugs.debian.org

Subject: Re: Bug#862475: The State of the YAML

Date: Fri, 18 May 2018 09:42:33 +0000

-=| gregor herrmann, 18.05.2018 11:09:23 +0200 |=-
> Quick status update on the perl YAML modules and the problem of
> instantiating objects:
> 
> * libyaml-syck-perl has $YAML::LoadBlessed since a long time
> * libyaml-libyaml-perl since 0.69 and libyaml-perl since 1.25 have
>   added $YAML::LoadBlessed as well
> * all three by default set it to 1 
> 
> (and YAML::Tiny is not affected as far as I know)
> 
> So I guess we have to consider if we're happy with the ability to
> turn off loading objects and recommend it to consumers and close the
> bugs; or if we want to change the defaults, which means setting
> $YAML::LoadBlessed to 0 in all three packages.

FWIW I'd go with the second option, with a note in debian/NEWS.

For me the cost of the possible breakage (easily fixed) is less than 
the gain of protecting everyone else.

(I don't use the object instantiation functionality)


-- dam

Message #81 received at 862373@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 862475@bugs.debian.org, 862373@bugs.debian.org

Subject: Re: Bug#862475: The State of the YAML

Date: Fri, 18 May 2018 07:59:29 -0400

Damyan Ivanov:
> -=| gregor herrmann, 18.05.2018 11:09:23 +0200 |=-
>> So I guess we have to consider if we're happy with the ability to
>> turn off loading objects and recommend it to consumers and close the
>> bugs; or if we want to change the defaults, which means setting
>> $YAML::LoadBlessed to 0 in all three packages.

> FWIW I'd go with the second option, with a note in debian/NEWS.

> For me the cost of the possible breakage (easily fixed) is less than 
> the gain of protecting everyone else.

+1

Message #88 received at 862373@bugs.debian.org (full text, mbox, reply):

From: shirish शिरीष <shirishag75@gmail.com>

To: 862373@bugs.debian.org

Subject: any update on the libyaml-libyaml-perl bug ?

Date: Sun, 19 Aug 2018 17:50:46 +0530

Dear all,

I was trying to install lintian when saw the above -

$ sudo aptitude install lintian -y
The following NEW packages will be installed:
  libyaml-libyaml-perl{a} lintian
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,161 kB of archives. After unpacking 4,350 kB will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of libyaml-libyaml-perl (→ 0.72+repack-1) <Forwarded>
 b1 - #862373 - libyaml-libyaml-perl: Unconditionally instantiates
objects from yaml data
Summary:
 libyaml-libyaml-perl(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] n
**********************************************************************
****** Exiting with an error in order to stop the installation. ******
**********************************************************************
E: Sub-process /usr/sbin/apt-listbugs apt returned an error code (10)
E: Failure running script /usr/sbin/apt-listbugs apt


I tried to see if another version is in experimental or something but
saw nothing -

$ apt-cache policy libyaml-libyaml-perl
libyaml-libyaml-perl:
  Installed: (none)
  Candidate: 0.72+repack-1
  Version table:
     0.72+repack-1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 http://deb.debian.org/debian unstable/main amd64 Packages


Then tried to see if a transition slot  has been asked for but
couldn't  find anything at least  in the list -

https://release.debian.org/transitions/

AIUI , we use transitions to add breaks against old versions and
rebuild packages with new package versions etc.

Looking forward to know as and when this is resolved.

-- 
          Regards,
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Message #93 received at 862373@bugs.debian.org (full text, mbox, reply):

From: Ivo De Decker <ivodd@debian.org>

To: gregor herrmann <gregoa@debian.org>

Cc: 862373@bugs.debian.org, 862475@bugs.debian.org

Subject: Re: The State of the YAML

Date: Mon, 11 Mar 2019 22:14:13 +0100

Control: tags -1 buster-ignore

Hi,

On Fri, May 18, 2018 at 11:09:23AM +0200, gregor herrmann wrote:
> Quick status update on the perl YAML modules and the problem of
> instantiating objects:
> 
> * libyaml-syck-perl has $YAML::LoadBlessed since a long time
> * libyaml-libyaml-perl since 0.69 and libyaml-perl since 1.25 have
>   added $YAML::LoadBlessed as well
> * all three by default set it to 1 
> 
> (and YAML::Tiny is not affected as far as I know)
> 
> So I guess we have to consider if we're happy with the ability to
> turn off loading objects and recommend it to consumers and close the
> bugs; or if we want to change the defaults, which means setting
> $YAML::LoadBlessed to 0 in all three packages.

I guess it might be best to change the default, but that's obviously too late
for buster. If this options is chosen, it should probably be done soon after
the buster release, to allow for plenty of time for issues to be discovered
(and fixed) for bullseye.

Thanks,

Ivo

Message #100 received at 862373@bugs.debian.org (full text, mbox, reply):

From: gregor herrmann <gregoa@debian.org>

To: Ivo De Decker <ivodd@debian.org>

Cc: 862373@bugs.debian.org, 862475@bugs.debian.org

Subject: Re: The State of the YAML

Date: Mon, 11 Mar 2019 22:24:31 +0100

[Message part 1 (text/plain, inline)]

On Mon, 11 Mar 2019 22:14:13 +0100, Ivo De Decker wrote:

> Control: tags -1 buster-ignore

Thanks.
 
> > So I guess we have to consider if we're happy with the ability to
> > turn off loading objects and recommend it to consumers and close the
> > bugs; or if we want to change the defaults, which means setting
> > $YAML::LoadBlessed to 0 in all three packages.
> I guess it might be best to change the default, but that's obviously too late
> for buster. If this options is chosen, it should probably be done soon after
> the buster release, to allow for plenty of time for issues to be discovered
> (and fixed) for bullseye.

Ack; we discussed this on IRC some time ago, and I also had a talk
with one of the upstream developers in August (about an upstream
change of the default), but apparently this slipped off of
everybody's radar afterwards; and we should indeed fix this quickly
in the bullseye cycle.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Chavela Vargas: Toda Una Vida

[signature.asc (application/pgp-signature, inline)]

Message #105 received at 862373-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 862373-close@bugs.debian.org

Subject: Bug#862373: fixed in libyaml-libyaml-perl 0.81+repack-1

Date: Wed, 29 Jan 2020 11:35:21 +0000

Source: libyaml-libyaml-perl
Source-Version: 0.81+repack-1

We believe that the bug you reported is fixed in the latest version of
libyaml-libyaml-perl, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 862373@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
gregor herrmann <gregoa@debian.org> (supplier of updated libyaml-libyaml-perl package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Wed, 29 Jan 2020 12:19:37 +0100
Source: libyaml-libyaml-perl
Architecture: source
Version: 0.81+repack-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Changed-By: gregor herrmann <gregoa@debian.org>
Closes: 862373
Changes:
 libyaml-libyaml-perl (0.81+repack-1) unstable; urgency=medium
 .
   * Import upstream version 0.81+repack.
     Fixes "Unconditionally instantiates objects from yaml data"
     (Closes: #862373)
   * Add a debian/NEWS entry about the changed default for
     $YAML::XS::LoadBlessed.
   * Update years of upstream and packaging copyright.
   * Declare compliance with Debian Policy 4.5.0.
   * Update Build-Depends for cross builds.
   * Set upstream metadata fields: Bug-Submit.
Checksums-Sha1:
 ae392d2a56699d8a66d3b5f0ae2f0a864b8f9bec 2461 libyaml-libyaml-perl_0.81+repack-1.dsc
 138a2ef9961c638c36533f12ee24b867193baa4a 80784 libyaml-libyaml-perl_0.81+repack.orig.tar.xz
 c23b065066c3babab5ced8737c7d8649627e4696 5620 libyaml-libyaml-perl_0.81+repack-1.debian.tar.xz
Checksums-Sha256:
 5af83154f1798189ab8755a67012c2e9dcbe4d9311b1da8c35a9391184aca0ca 2461 libyaml-libyaml-perl_0.81+repack-1.dsc
 8d3cfe2a9428f117d2dc49571bfb3b5724f540d65b6f67795168acb2c1b8bd1d 80784 libyaml-libyaml-perl_0.81+repack.orig.tar.xz
 7fbf9e63535fd2827a42130250df52a7ebf786efb78a41a0b5a382ff052240d1 5620 libyaml-libyaml-perl_0.81+repack-1.debian.tar.xz
Files:
 9738b50861901f9295c92dbb15c8ad54 2461 perl optional libyaml-libyaml-perl_0.81+repack-1.dsc
 0eff92b8a2c4aab7703227427d58acae 80784 perl optional libyaml-libyaml-perl_0.81+repack.orig.tar.xz
 7aeaddc5f4a98665348a9db1b0718f90 5620 perl optional libyaml-libyaml-perl_0.81+repack-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl4xattfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYiNA//dO9dFzMbBoOYdZrd3kiIKuHaOO5CNs9CVth1w/7WUcsZQhfyizfPBub8
4wjMSgKfvKEE3jHBQFeMiiEEhaDu4zZyPdAaAC4fAB5IN+0tMF9Wxyip/3r2jH0x
dG9p5zx+rsEOR7SSanhyt5np5Rhw7TbbTn5Nl1nYyc4FRbIWhksAQ7NAgrF5mcNh
SwOl3IZ9xUWCmQZGn7gjy8Wllhfv5qBeAnHcZPElLWqSYSt7J05P5So1ktNFUJqO
LY2w2AYV1DjZGR+pyCee7XY84pnQT7UzqWjxpUzVctwQd+DqXfFMUY45WSTvZdEY
o3PyY7623sQq8v88itTon8Da+M+7TJf6ki9TzG9sUG0blY5KMnCu6U3okVIVeDX6
9seXPmHtFgUsLc6WCt6HpP/4UnrNbVn0sBLDiSjJLezId2X8k3oYTyC/HKdSDxll
mvc8vxQJqF78SNkUJJPck9eQgmnu++0lw4BBIUiF8Pjf8CyMdyQSFtunXoVdZXWI
jAWRYNkUE5xxVmZyLK7/4/DLqy0N8KHP7dtD1louCZx3YPnbNUvBziNOyRih4vH9
RTxbjdjvnWvL/39mL3mwor8B9LsiYRZ3YlZdIW+u2cXRkUA7XCvnqfVk5sbBth1S
4e7Bg4dR4QW02CiWqA8rRh4cV4u6yeUzP4dsMQGfLdKuNqzJ+0Q=
=aVlS
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.