Bug#571623: "version: !perl/Module::Build::Version" results in broken Debian version
Jozef Kutej writes:
> Ansgar Burchardt wrote:
>> A YAML file can call constructors for all loaded modules? That would
>
> no, not constructors, there is even no way of knowing what is the name
> of constructor, but even just by loading a module it is code
> execution. mostly the code that makes the initialization and
> import().
That can still result in interesting behaviour together with
overloading. For example the attached program will access the Internet
and the value of $data->{foo}->{content} can change between the two
print statements (influenced by whoever operates the server).
This just waits for somebody to find a way to abuse this...
Regards,
Ansgar
#! /usr/bin/perl
package Foo;
use overload '%{}' => \&f;
use LWP::Simple;
sub new {
bless shift;
}
sub f {
my $self = shift;
bless $self, 'overload::dummy';
my $content = get($self->{url});
bless $self, 'Foo';
return { content => $content };
}
1;
package main;
use YAML::Syck;
my $foo = Foo::new { url => "http://www.google.com/"; };
my $data = LoadFile(\*DATA);
# validate data
print $data->{foo}->{content};
# now do something with the validated data
print $data->{foo}->{content};
1;
__DATA__
---
foo: !perl/Foo
url: http://www.example.org/
Bug#571623: "version: !perl/Module::Build::Version" results in broken Debian version
Ansgar Burchardt wrote: > A YAML file can call constructors for all loaded modules? That would no, not constructors, there is even no way of knowing what is the name of constructor, but even just by loading a module it is code execution. mostly the code that makes the initialization and import(). i can ask the authors of YAML or YAML::Syck what do they think about loading the modules that are declared inside YAML. if the current status, that the modules are not loaded, is a bug or a feature? Cheers, Jozef -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571623: "version: !perl/Module::Build::Version" results in broken Debian version
Hi, Jozef Kutej writes: > Damyan Ivanov wrote: >> Shouldn't this be loaded by the module which parses META.yml? In >> dh-make-perl's case this is the YAML module (I also tried with >> YAML::Syck and YAML::XS). > > hmm that could be a security risk, if by loading yaml file some other > module would be automatically loaded, or? A YAML file can call constructors for all loaded modules? That would seem rather strange to me and might open lots of security holes when loading an untrusted YAML file (you cannot assume that all modules have safe constructors). Or did I understand something wrong? Regards, Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571623: "version: !perl/Module::Build::Version" results in broken Debian version
Damyan Ivanov wrote:
> Shouldn't this be loaded by the module which parses META.yml? In
> dh-make-perl's case this is the YAML module (I also tried with
> YAML::Syck and YAML::XS).
hmm that could be a security risk, if by loading yaml file some other module
would be automatically loaded, or?
> I mean, how would dh-make-perl know that it has to pre-load module X?
Class-Accessor-Assert-1.40$ perl -MScalar::Util=blessed -MYAML::Syck -le 'print
blessed LoadFile("META.yml")->{'version'}'
Module::Build::Version
so it is theoretically possible to get the class if the version is blessed and
then load it if not loaded. but i would go for a safe choice of just adding "use
Module::Build::Version;" line to DhMakePerl.pm. if there will be more META.yml-s
with strange classes than it could be reconsidered.
still i can send a patch that will load the {'version'} class if you'll want it.
j
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571623: "version: !perl/Module::Build::Version" results in broken Debian version
-=| Jozef Kutej, Fri, Feb 26, 2010 at 03:44:41PM +0100 |=- > Package: dh-make-perl > Version: 0.63 > Severity: minor > > Some authors use "version: !perl/Module::Build::Version" in META.yml. Like > for > example > http://cpansearch.perl.org/src/SMUELLER/Class-Accessor-Assert-1.40/META.yml > which results in: > > Found: Class-Accessor-Assert 0Module-Build-Version-HASH-0xa487160- > (libclass-accessor-assert-perl arch=all) > > The solution will be to load "Module::Build::Version" in DhMakePerl.pm. Shouldn't this be loaded by the module which parses META.yml? In dh-make-perl's case this is the YAML module (I also tried with YAML::Syck and YAML::XS). I mean, how would dh-make-perl know that it has to pre-load module X? > Example: > > Class-Accessor-Assert-1.40$ /usr/bin/dh-make-perl > Found: Class-Accessor-Assert 0Module-Build-Version-HASH-0x9872160- > (libclass-accessor-assert-perl arch=all) Note to self: in order to reproduce, do not use --cpan option, because it loads CPAN, which loads Module::Build, which loads M::B::Version. signature.asc Description: Digital signature
Bug#571623: "version: !perl/Module::Build::Version" results in broken Debian version
Package: dh-make-perl Version: 0.63 Severity: minor Some authors use "version: !perl/Module::Build::Version" in META.yml. Like for example http://cpansearch.perl.org/src/SMUELLER/Class-Accessor-Assert-1.40/META.yml which results in: Found: Class-Accessor-Assert 0Module-Build-Version-HASH-0xa487160- (libclass-accessor-assert-perl arch=all) The solution will be to load "Module::Build::Version" in DhMakePerl.pm. Example: Class-Accessor-Assert-1.40$ /usr/bin/dh-make-perl Found: Class-Accessor-Assert 0Module-Build-Version-HASH-0x9872160- (libclass-accessor-assert-perl arch=all) ... Class-Accessor-Assert-1.40$ perl -MModule::Build::Version /usr/bin/dh-make-perl Found: Class-Accessor-Assert 1.40 (libclass-accessor-assert-perl arch=all) ... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dh-make-perl depends on: ii debhelper 7.4.13 helper programs for debian/rules ii dpkg-dev 1.15.5.6 Debian package development tools ii fakeroot 1.14.4-1 Gives a fake root environment ii libapt-pkg-perl 0.1.24 Perl interface to libapt-pkg ii libarray-unique-perl 0.08-1 Tie-able array that allows only un ii libclass-accessor-perl0.34-1 Perl module that automatically gen ii libemail-date-format-perl 1.002-1Module to generate RFC-2822-valid ii liblist-moreutils-perl0.25~02-1 Perl module with additional list f ii libmodule-corelist-perl 2.25-1 module to determine modules shippe ii libmodule-depends-perl0.14-3 identify the dependencies of a dis ii libparse-debcontrol-perl 2.005-2Easy OO parsing of Debian control- ii libparse-debianchangelog-perl 1.1.1-2parse Debian changelogs and output ii libtie-ixhash-perl1.21-2 ordered associative arrays for Per ii libwww-mechanize-perl 1.58-1 module to automate interaction wit ii libyaml-perl 0.71-1 YAML Ain't Markup Language ii make 3.81-7 An utility for Directing compilati ii perl 5.10.1-11 Larry Wall's Practical Extraction ii perl-modules [libmodule-corel 5.10.1-11 Core Perl modules Versions of packages dh-make-perl recommends: ii apt-file 2.3.3 search for files within Debian pac dh-make-perl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
