Perldoc security issues

[James Taylor]

I've created a very simple web-based perldoc interface that
simply passes the options and arguments the user enters to
perldoc via the shell, but before I release it I'd like to ask
if anyone is aware of any security issues with perldoc that I
should defend against. I know little about perldoc's many
options or whether they are abusable and would really appreciate
some pointers. For instance, it's not clear to me whether it
would be possible to use some of perldoc's more esoteric options
to write to another file, or execute another file even.

Of course, there are shell related security issues too. Those
that come to mind are semicolons, pipes, and i/o redirectors.
I therefore remove most punctuation characters from the user
input before passing it to the shell with a tr:

$query =~ tr/- _A-Za-z0-9:"'//cd;

I have left colons so people can look up modules, and quote marks
so people can quote phrases to look up in the FAQ. This should
allow most of the common perldoc references given in this group
to be looked up, but would exclude interesting regexes. However,
if I can be a little less paranoid and allow more without
sacrificing security that would be good too.

Can anyone offer me general guidance?

I can post source code if that would be useful. It's only 78 lines.

Thanks.

 

[John Bokma]

Of course, there are shell related security issues too. Those
that come to mind are semicolons, pipes, and i/o redirectors.
I therefore remove most punctuation characters from the user
input before passing it to the shell with a tr:

$query =~ tr/- _A-Za-z0-9:"'//cd;

Technically you should write down each and every thing you are 100% sure
that is allowed and reject everything that doesn't fall into this set. With
general regexps and friends you either overlook things or break things.

Never fix input, like you do above.

I have left colons so people can look up modules, and quote marks
so people can quote phrases to look up in the FAQ.

But don't do that with a regexp. Use a parser.

 

[James Taylor]

Technically you should write down each and every thing you are
100% sure that is allowed and reject everything that doesn't
fall into this set.

Well, ideally I should just make it perfect, of course.
However, as time is limited and I'm a practical kind of guy,
I'm looking for a simple, minimally sufficient solution.

With general regexps and friends you either overlook
things or break things.

Yes, I agree that it would be inappropriate to try to parse and
validate full regex syntax, and quite disproportionate to the
size of the task at hand. Pragmatic compromise is the way to go.

Never fix input, like you do above.

Never? What's the right way to tidy user input in this situation?
Obviously, as I'm not getting paid by the hour, I'd like a
lightweight solution; something I can knock up over lunch in a
few lines of code, not an over-engineered solution involving
multiple chunks of OPC.

But don't do that with a regexp. Use a parser.

Why use a sledgehammer when a nutcracker will do?

 

[Tad McClellan]

I've created a very simple web-based perldoc interface that
simply passes the options and arguments the user enters to
perldoc via the shell, but before I release it I'd like to ask
if anyone is aware of any security issues with perldoc that I
should defend against. I know little about perldoc's many
options or whether they are abusable and would really appreciate
some pointers. For instance, it's not clear to me whether it
would be possible to use some of perldoc's more esoteric options
to write to another file, or execute another file even.

Then disallow any functions that you are wary of.

Of course, there are shell related security issues too. Those
that come to mind are semicolons, pipes, and i/o redirectors.
I therefore remove most punctuation characters from the user
input before passing it to the shell with a tr:

$query =~ tr/- _A-Za-z0-9:"'//cd;

You should fail to run rather than repair input and then run.

You should specify what you will allow rather than what you will forbid.

I have left colons so people can look up modules, and quote marks
so people can quote phrases to look up in the FAQ. This should
allow most of the common perldoc references given in this group
to be looked up, but would exclude interesting regexes. However,
if I can be a little less paranoid and allow more without
sacrificing security that would be good too.

Can anyone offer me general guidance?

if ( $ARGV[0] eq '-f' and $ARGV[1] =~ /^\w+$/ )
{ perldoc_f() }
}
elsif ( $ARGV[0] eq '-q' and
( $ARGV[1] =~ /^[\w ]+$/ or $ARGV[1] =~ /^(['"])[\w ]+\1$/ )
{ perldoc_q() }
}
elsif ( $ARGV[0] =~ /^(\w|:+$/ ) {
perldoc();
}
else {
fail();
}

 

[John Bokma]

Never? What's the right way to tidy user input in this situation?

If it's unexpected input, don't fix it. It was wrong in the first place.

Obviously, as I'm not getting paid by the hour, I'd like a
lightweight solution; something I can knock up over lunch in a
few lines of code, not an over-engineered solution involving
multiple chunks of OPC.

It probably has been done before, I know there is at least one interface to
perldoc on line.

Why use a sledgehammer when a nutcracker will do?

You misread my post: regexp will *not* do what you want. You asked for
security, you won't get that with a regexp (or several).

 

[Anno Siegel]

John Bokma <[email protected]> wrote:

[security advice]

Well, ideally I should just make it perfect, of course.
I'm looking for a simple, minimally sufficient solution.
[advice]

Pragmatic compromise is the way to go.
[advice]

I'd like a lightweight solution; something I can knock up over lunch in a
[advice]

Why use a sledgehammer when a nutcracker will do?

In view of this attitude one has to wonder why you asked about security
in the first place. You are obviously determined not to invest any more
effort than you already have. Answering was a waste of time.

Anno

 

[James Taylor]

Then disallow any functions that you are wary of.

Well, I could do that, but then I would be restricting people's
legitimate use of perldoc, and one of the primary purposes of
my interface is to give those without a native perldoc the ability
to see how perldoc works and what it returns for any combination
of options and arguments that they might see given in this group.

You should fail to run rather than repair input and then run.

Yes, okay.

You should specify what you will allow rather than what you
will forbid.

Yes, of course, although this means rather more coding. :-(

if ( $ARGV[0] eq '-f' and $ARGV[1] =~ /^\w+$/ )
{ perldoc_f() }
}
elsif ( $ARGV[0] eq '-q' and
( $ARGV[1] =~ /^[\w ]+$/ or $ARGV[1] =~ /^(['"])[\w ]+\1$/ )
{ perldoc_q() }
}
elsif ( $ARGV[0] =~ /^(\w|:+$/ ) {
perldoc();
}
else {
fail();
}

That kind of thing seems a reasonable approach so I'll extrapolate
that example to all the other options, assuming I can guess
correctly how to use them. Thanks.

 

[James Taylor]

In view of this attitude one has to wonder why you asked about
security in the first place. You are obviously determined not
to invest any more effort than you already have.

I think you misunderstand. I just wanted the size of the solution
to be in the same ball park as the size of the problem; something
doable in the kind of time the task deserves. Anyway, I refute your
apparent belief that a secure script requires a large or complex
solution. Merely disallowing any options would suffice (although
in this particular case it would be too Draconian for my purposes).

In the real world you have to compromise on perfection, otherwise
you'd spend so much time perfecting a solution to the first small
task you came across that you'd never move on to the second, or
third, or the rest of your life! Sadly, in this world, you don't
get paid for perfectionism, you get paid for getting the job done.
Don't forget that Perl is *the* language for getting the job done.

It amuses me how often small questions in this group are answered
with disproportionately large and idealistic solutions. This
invariably results in the questioner squirming for a way to get
a more pragmatic answer without seeming ungrateful. They then get
attacked as obstinate, clueless, or even wilfully lazy in much
the same way as you've just had a go at me. When I'm watching
this happen to someone else I can laugh and shake my head in
wonder at how people can be so lacking in self-awareness. As it's
happening to me this time, I must ask you to take a long hard
look at the position you're taking and be more reasonable.

Answering was a waste of time.

Absolutely not. The answers have all been very useful thanks,
....with the possible exception of yours, of course. ;-)

 

[James Taylor]

If it's unexpected input, don't fix it. It was wrong in the first place.

Okay, I see what you mean. I'll raise an error instead.

You misread my post: regexp will *not* do what you want.
You asked for security, you won't get that with a regexp (or several).

Actually, you can, by following the example Tad gave.

 

[Anno Siegel]

I think you misunderstand. I just wanted the size of the solution
to be in the same ball park as the size of the problem; something
doable in the kind of time the task deserves.

Then you don't want a secure solution, you want something in between.
That's your call and only yours. We don't know the size of the problem
and how much time the task deserves. Nor do we know what is at stake
in case of a security breach. We don't even know what system you're
using and what shell, if any, will interpret commands. Security
with system() is mostly shell-dependent.

Anyway, I refute your
apparent belief that a secure script requires a large or complex
solution.

I have uttered no such belief. You have rejected concrete proposals
as too complex.

Merely disallowing any options would suffice (although
in this particular case it would be too Draconian for my purposes).

If you say so... No way for us to know.

[...]

It amuses me how often small questions in this group are answered
with disproportionately large and idealistic solutions. This
invariably results in the questioner squirming for a way to get
a more pragmatic answer without seeming ungrateful.

Your question was:

Can anyone offer me general guidance?

What did you expect, in a security context?

Anno