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@chiark.greenend.org.uk> 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
before.
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.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄⠀⠀⠀⠀
Reply to: