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
affected...
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: