Web lists-archives.com

Re: Potentially insecure Perl scripts

On Thu, Jan 24, 2019 at 04:41:29AM +0000, Ben Hutchings wrote:
> On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote:
> > Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> writes:
> > > Apparently this has been klnown about for EIGHTEEN YEARS
> > >   https://rt.perl.org/Public/Bug/Display.html?id=2783
> > > and no-one has fixed it or even documented it.
> > 
> > It's been documented for pretty close to eighteen years too.  See
> > perlop(1):
> > 
> >        The null filehandle "<>" is special: it can be used to emulate the
> >        behavior of sed and awk, and any other Unix filter program that
> >        takes a list of filenames, doing the same to each line of input
> >        from all of them.  Input from "<>" comes either from standard
> >        input, or from each file listed on the command line.
> But this initial description is actively misleading.  It doesn't matter
> that the giant booby-trap is documented several paragraphs further
> down.  Why would a programmer expect that they need to read further
> when they already understand this Unix convention?
> There should be a big flashing WARNING or DEPRECATED right at the top
> of the description.

Even that wouldn't be enough.  This won't help those who learned Perl

I for one did most of my Perl learning ~20 years ago (so just before those
"EIGHTEEN YEARS" you name), and I guess a good deal of Perl users are
similar -- those pesky annoying millenials seem to use exclusively Python,
Perl users being correlated to low-saturation colors of beard.  Yet <>
being broken in such a fundamental way is news to me.  And I don't quite
see any way you could communicate that to me in a way other than a
run-time warning -- you don't re-read docs for basics you believe you
already know well.

> > > I think this is a serious bug in Perl which should be fixed in a
> > > security update.
> > 
> > There is absolutely no way.  So much stuff in Perl depends on this.  You
> > will break all kinds of scripts.  It's been a feature of the language for
> > basically forever.

A run-time warning is annoying but I'd find it warranted.  Just like many
features of C that started printing warnings, you can silence them with
「no warnings 'foo::bar';」.

> People have said this about ASLR, protected symlinks, and many other
> kinds of security hardening changes.  We made them anyway and took the
> temporary pain for a long-term security gain.

In this thread, this [mis?]feature of <> has been likened to strcpy().  It's
much worse -- not to the point of gets() but very similar to strncpy() --
something that _looks_ good but is almost never used right.

⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.