Re: [perl #2783] Security of ARGV using 2-argument open - It's a feature

Tom Christiansen <tchrist <at> perl.com> writes:

>>I find it incredibly aggravating that my one-liners do the wrong thing
>>when they attempt to read my files <.st and >.st.

>People who create files with aggravating names are aggravating people; 
>just say no.

>If it takes a syswide find to locate unpleasant filenames and send
>whingeing or abusive or threatening mail (interpretation rests on the
>receiver) about the inadvisability of files with whitespace or brackets,
>or question-marks or stars, (and for perl, also minuses, ampersands,
>equals, or pipes), then that's a local administration issue.

You seem to have in mind the comfortable Unix environment most of us remember
from university days (or elsewhere), when your local bearded sysadmin would keep
a watchful eye on the students and make sure that the local collection of
eclectic, flaky but nonetheless lovable administrative shell scripts kept
working smoothly.  I am not saying that is a bad ideal at all.  But it's not the
issue here.

You can't run a system-wide check for 'unpleasant' filenames before every
invocation of your perl program.  And although someone deliberately making a
file '| rm -rf /' is the example we all use (and a good enough example in its
own right to make this worth fixing, IMHO), in practice a successful attack to
get control of a computer often uses several stages.  The first stage might be
to trick a slightly dopey CGI script into making a filename containing a '|'
character in its temporary directory - not a security hole in itself, right? and
then wait for an administrative Perl script run by root to 'while (<>)' in that
directory.  Or indeed the same CGI script might use the 'while (<>)' construct -
which is surely just reading some files and should be safe, right?

Remember that here we're not talking about some obscure construct that only
experts know, where people can be expected to read about the security risks and
gotchas before using it.  This is pretty much in the first chapter of every
beginner's Perl tutorial - yet few of them have any warning that it might do
unexpected things if a file in the current directory is 'unpleasant'.  Surely we
have a duty to make sure that the code recommended to novices is totally safe to
use.

But security holes are just one specific class of bugs.  In principle, the issue
is that asking perl to read some files should work 100% of the time.  Not some
of the time depending on what filenames exist.

>And the day that I can no longer rely upon the overlying system to
>automatically understand that "-" is STDIN for input or STDOUT for output
>is the day that I will fork a parallel copy of Perl that maintains
>traditional and expected behavior.

If I might go rhetorical for a moment: to rely upon the overlying system?  That
seems like a very good idea.  So the C library itself should interpret '-' to
mean stdin or stdout, it shouldn't be implemented afresh in every application
like perl, grep, tar and so on.

So why doesn't the C library automatically treat '-' as stdin or stdout?

>What you don't seem to understand is that taking a homogeneous approach to
>argument processing is not a bug, but a feature--a BIG FEATURE.  Perhaps
>you're too much of a youngster to remember the days that shells didn't glob
>command-line arguments for you, and each program had to parse and process
>its own command line string.  But I am not.  Those were dark days of
>unpredictability.  It's the wrong way to (not) go about things.

Absolutely.  It would be crazy for perl or any other program to start doing
argument processing that better belongs in the shell.  Imagine if shells didn't
support commands like

% cat <(echo hello; echo goodbye)

and cat, and every other program, had to have special code to recognize '<' in
its arguments.  It would be a terrible mess - and you'd need another layer of
mess to handle the case when '<' really is in a filename.  Much better to let
the shell do it.

>When you make every program encode the logic of treating "-" as special,
>you are making a very big mistake.  Some programs shall, others shan't.

>You would ask this sort of idiocy:
>
>    % perl -le 'open(IT, ">", "-")||die; print IT "stuff"; close(IT)||die'
>    % cat ./-
>    stuff

That's exactly the behaviour I see with perl 5.10.  What result do you get?

-- 
Ed Avis <eda@waniasset.com>

• Re: [perl #2783] Security of ARGV using 2-argument open - It's a feature by Ed Avis
• Re: [perl #2783] Security of ARGV using 2-argument open - It's afeature by Abigail