[perl #122807] [demerphq] Re: fix for CVE-2014-4330 present in blead

On Sat Sep 20 05:07:10 2014, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
> >>>>> On Sat, 20 Sep 2014 05:47:14 +0200, demerphq <demerphq@gmail.com>
> >>>>> said:
> 
> > On 20 September 2014 05:16, Andreas Koenig <
> > andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
> 
> >>>>>> On Fri, 19 Sep 2014 06:22:04 +0200, demerphq
> >>>>>> <demerphq@gmail.com>
> > said:
> 
> >>> I expressed an opinion that DD is generally unsuitable as a
> >>> serialization tool, perhaps a touch inappropriately worded mind
> >>> you.
> 
> >> Thank you.
> 
> > You are welcome. But I have to say I am bit confused as to the
> > purpose of this
> > ticket. Was it to find out if there was undocumented reasons?
> 
> The purpose of this ticket is trivial: you say DD is broken, I find
> this
> is undocumented, so it must have consequences.
> 
> That said, I'm not sure where this ticket will lead us. If
> Data::Dumper
> is seriously broken we need to (1) either remove it from core or (2)
> fix
> it or (3) document where it fails or (4) find some other settlement
> that
> may be worked out in this ticket. I was not the one who brought the
> topic up, I opened the ticket because is is an unacceptable situation.
> 
> >>> The reason are as follows:
> 
> >>> DD is incapable of serializing correctly many of the data
> >>> structures Perl can produce.
> 
> >> This is documented.
> 
> > Is it? I am unaware of them. An example of something DD doesnt dump
> > right:
> 
> > perl -MData::Dumper -le'my @array; $array[0]=\$array[1];
> > $array[1]=\$array[0];
> > print Data::Dumper->new([\@array],[qw(*array)])->Purity(1)->Dump'
> > @array = (
> >            \\do{my $o},
> >            do{my $o}
> >          );
> > ${${$array[0]}} = $array[0];
> > $array[1] = ${$array[0]};
> 
> I stand corrected, this seems undocumented.
> 
> >>> DD is incapable of round tripping many data structures,
> 
> >> This is documented.
> 
> > Again, I am not familiar with where.
> 
> I suppose this extra paragraph is a subcase of the above example? I
> don't know.
> 
> >>> even ones as simple as strings properly.
> 
> >> I could not find this documented, can you please elaborate?
> 
> > $ perl -MData::Dumper -le'my $str="hello\tthere\n";
> > utf8::upgrade($str); print
> > Data::Dumper->new([$str],["*str"])->Purity(1)->Useqq(1)->Dump()'
> > $str = "hello\tthere\n";
> 
> > That $str is not going to eval back with the utf8 flag set.
> 
> > Another example:
> 
> > $ perl -MData::Dumper -le'my $str="\0\1\2"; utf8::upgrade($str);
> > print
> > Data::Dumper->new([$str],["*str"])->Purity(1)->Useqq(1)->Dump()'
> > $str = "\0\1\2";
> 
> > That one actually I think is a regression, IIRC we used to output
> > this as:
> 
> > $str = "\x{0}\x{1}\x{2}";
> 
> > Which a module like Data::Undump uses to know that the string should
> > end up
> > utf8 on. Anyway, the point still holds, the utf8ness of the string is
> > not going
> > to be preserved.
> 
> > Another example:
> 
> > perl -MData::Dumper -le'my $str="\0\1\2";
> > Internals::SvREADONLY($str,1); Dump
> > ($str); print Data::Dumper->new([$str],["*str"])->Purity(1)-
> > >Useqq(1)->Dump()'
> 
> > The readonly flag will not round trip.
> >
> 
> Aha, these exampes look like you were talking about internal flags.
> Maybe that would not be too hard to document that internal flags like
> those are not preserved. What's your opinion?
> 
> >>> DD requires eval to deserialize, making its use as a serialization
> >>> format insecure.
> 
> >> This is documented.
> 
> > Yes, I rather suspect it is.
> 
> Good.
> 
> >>> Data::Undump somewhat addresses this, but only to a certain
> >>> extent. DD is generally inefficient, both in implementation and in
> >>> terms of output size, and eval is slow as well.
> 
> >> This may be relevant but does not necessarily need to be documented.
> 
> > Ok.
> 
> Great.
> 
> >>> As a debugging/diagnostics tool DD is pretty good, but even for
> >>> that purpose there are better tools like Data::Dump::Streamer,
> >>> assuming performance is not an issue (even for debugging
> >>> performance can be an issue.)
> 
> >> Ditto.
> 
> > I would say that DD should probably reference DDS as an alternative.
> 
> Fine by me.
> 
> >>> If you want to serialize Perl data then IMO you have a number of
> >>> other choices with different trade offs, all of which are pretty
> >>> much superior to DD:
> 
> >>> [...]
> 
> >> I don't think that the manpage for DD needs to mention all
> >> alternatives
> >> there are on CPAN as long as DD itself is basically doing its job.
> 
> > Well, I thought the point of this thread was why people shouldnt
> > think of DD as
> > a good tool for serializing data. It really really isnt.
> 
> The point of this ticket is to fix bugs, be it documentations bugs,
> packaging bugs, code bugs or bugs that fall in any other category.
> 
> > And if it isnt it should probably reference modules that are.
> 
> Fine by me.
> 
> Would you mind providing a patch?

A CVE related bug seems like we should be addressing it
-- 
Karl Williamson

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=122807

• [perl #122807] [demerphq] Re: fix for CVE-2014-4330 present in blead by Karl Williamson via RT