[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Potentially insecure Perl scripts

On 1/24/19 2:40 AM, Vincent Lefevre wrote:
> On 2019-01-23 17:23:10 +0100, Alex Mestiashvili wrote:
>> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
>>> On 2019-01-23 15:32:00 +0000, Ian Jackson wrote:
>>>> This is completely mad and IMO the bug is in perl, not in all of the
>>>> millions of perl scripts that used <> thinking it was a sensible thing
>>>> to write.
>>> I agree that it would be better to drop this "feature" of Perl.
>>> It is probably never used, and probably useless (I would rather
>>> use the features from the shell if I need a pipe).
>> Perl's open is well documented.
> What wasn't clear was not about open, but the fact that <> uses the
> 2-arg open in a raw way. FYI, I learnt Perl in 1994 or early 1995,
> just after Perl 5.000 was released, and at that time, I'm not sure
> that <> was properly documented. More importantly, security was not
> really a consideration (not much except file permissions).
> The fact that the perlsec(1) man page doesn't mention the issue with
> the null filehandle doesn't help either.
> One also has (had) plenty of misleading documentation, starting with
> the perlrun(1) man page:
>        -n   causes Perl to assume the following loop around your
>             program, which makes it iterate over filename arguments
>             somewhat like sed -n or awk:
>               LINE:
>                 while (<>) {
>                     ...             # your program goes here
>                 }
> "like sed -n and awk". Really?
> Now, this man page also says:
>             Also note that "<>" passes command line arguments to
>             "open" in perlfunc, which doesn't necessarily interpret
>             them as file names.  See  perlop for possible security
>             implications.
> But in 2008, it was still not there. Thus programs written before 2008
> or by developers who started to learn Perl before 2008 can easily be
> affected by this issue.

Thank you for bringing this issue up.
Now, when I grepped through my /usr/bin and found a bunch of old scripts
affected by this I think you are totally right.

But I disagree that a language can be considered insecure, just because
it lets you shoot in the foot.
The first thing I learned when doing CGI coding is to sanitize the
input. That's the root problem in the most cases IMHO.
It's also good to see that perl's documentation gets improved.

> BTW, I've just seen that I already reported a documentation bug in
> the past:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592727
> This was about the behavior, which is not specified, e.g. on
> the argument '>file'.
>> Quoting the perlipc:
>> "it's much more efficient to process the file one line or record at a
>> time because then you don't have to read the whole thing into memory at
>> once."
> Well, with a pipe used from the shell (either with "|" or with
> process substitution) instead of a special Perl syntax, the
> behavior is the same.

This feature is heavily used. Just grepping over my /usr/bin found 31
scripts using this construct and a few of randomly picked up scripts are

May be lintian's warning for something like "while\s?(\s?<>\s?)" in perl
script explaining people that they should test the scripts is a good
start to eliminate that in Debian?

Reply to: