Perl CGI executing command line functions

[Nick]

I am just starting out with Perl and am trying to figure out how to
setup a CGI script to perform some command line functions. I work
with some people that need to run some command line functions but we
do not want to give them command line access. I thought that if I
write a Perl CGI script that executes some of the commands for them,
it would solve our problems.

I have found tons of examples and tutorials that show you how to get a
Perl CGI to write to files, display HTML pages and print lines. What
is the correct syntax for backticks in Perl? My goal was to give them
allow
them access to some HTML pages with some forms where they enter the
options for certain commands.

For example, if I had this as my HTML form and the user entered "-al"
<form action="dosomething.cgi" method="GET">
Enter an #ls option: <input type="text" name="commd" size=30><p>
<input type="submit">
</form>

How would I get Perl to run that #ls command with the user's option
values (#ls -al) and display the end result of that command?
Would it be something similar to
`ls` $commd;
How would I show the end result?

Thanks in advance,
Nick

 

[Michael Budash]

I am just starting out with Perl and am trying to figure out how to
setup a CGI script to perform some command line functions. I work
with some people that need to run some command line functions but we
do not want to give them command line access. I thought that if I
write a Perl CGI script that executes some of the commands for them,
it would solve our problems.

I have found tons of examples and tutorials that show you how to get a
Perl CGI to write to files, display HTML pages and print lines. What
is the correct syntax for backticks in Perl? My goal was to give them
allow
them access to some HTML pages with some forms where they enter the
options for certain commands.

For example, if I had this as my HTML form and the user entered "-al"
<form action="dosomething.cgi" method="GET">
Enter an #ls option: <input type="text" name="commd" size=30><p>
<input type="submit">
</form>

How would I get Perl to run that #ls command with the user's option
values (#ls -al) and display the end result of that command?
Would it be something similar to
`ls` $commd;
How would I show the end result?

Thanks in advance,
Nick

the most naive way would be this:

#----------------------------------------
#!perl -w

use strict;
use CGI qw/:standard/;

$|++;

print header();

my $commd = param('commd');

print `ls $commd`;
#----------------------------------------

however... think of what would happen if the user entered "; rm -fr *.*"
!!!!!!!

you might wanna constrain what is allowable...

 

[Gregory Toomey]

It was a dark and stormy night, and Nick managed to scribble:

I am just starting out with Perl and am trying to figure out how to
setup a CGI script to perform some command line functions. I work
with some people that need to run some command line functions but we
do not want to give them command line access. I thought that if I
write a Perl CGI script that executes some of the commands for them,
it would solve our problems.

Use the 'system' command. You will probably nned fully qualified paths if you use CGI.

gtoomey

 

[Gunnar Hjalmarsson]

I work with some people that need to run some command line
functions but we do not want to give them command line access. I
thought that if I write a Perl CGI script that executes some of the
commands for them, it would solve our problems.

*Some* of the commands? Do they have access to upload and run their
own CGI scripts? In that case, what prevents them from uploading a
script and executing *any* system command?

Just a thought.

For example, if I had this as my HTML form and the user entered
"-al"
<form action="dosomething.cgi" method="GET">
Enter an #ls option: <input type="text" name="commd" size=30><p>
<input type="submit">
</form>

How would I get Perl to run that #ls command with the user's option
values (#ls -al) and display the end result of that command?
Would it be something similar to
`ls` $commd;
How would I show the end result?

An example:

$result = `ls $commd 2>&1`;

The '2>&1' part makes it capture also possible error messages in $result.

 

[Tad McClellan]

I am just starting out with Perl and am trying to figure out how to
setup a CGI script

You should learn Perl itself first, before moving on to a
complicated application area such as CGI programs.

to perform some command line functions. I work
with some people that need to run some command line functions but we
do not want to give them command line access.

Why is it that you do not want to give them command line access?

I thought that if I
write a Perl CGI script that executes some of the commands for them,
it would solve our problems.

It seems much more likely to me to _cause_ more problems
that it solves.

I think we have an XY problem.

If you can answer the question above, we will be in a much better
postion to give good advice...

How would I get Perl to run that #ls command

What is the "#ls" command?

with the user's option

You better turn taint checking on (-T) and check the user's input
very very carefully. You have lots of chances of opening up a
security hole with your idea. Be careful.

values (#ls -al) and display the end result of that command?
Would it be something similar to
`ls` $commd;

Assuming that $commd has somehow gotten the corresponding value
from the form, hopefully by calling CGI:aram():

my $result = `ls $commd`;

How would I show the end result?

print $result;

If it is in a CGI program where the output is supposed to go
to STDOUT anyway, then you do not need to capture the output
at all:

print "Content-type: text/plain\n\n";
system "ls $commd";

 

[Nick]

Thanks guys.

(e-mail address removed) (Tad McClellan) wrote in message

You should learn Perl itself first, before moving on to a
complicated application area such as CGI programs.

sounds like a fine idea and I intend to do this but I was hoping I
could pick up enough to write this CGI program

Why is it that you do not want to give them command line access?

Our company has a policy that does not allow departments other than IT
to have command line access to the app servers. Another department in
our company uses a program that makes additions/changes to one of our
app servers & database and the only current way to make these specific
changes is for them to put in a request with the IT department to
manually type in this application's script.

*Some* of the commands? Do they have access to upload and run their
own CGI scripts? In that case, what prevents them from uploading a
script and executing *any* system command?

Yes, they do have this control but since they are part of our company
we trust them and the app server and database is their equipment, we
just run/houses/configure so it is unlikely they will do harm to their
own machines

An example:

$result = `ls $commd 2>&1`;

The '2>&1' part makes it capture also possible error messages in $result.

Thanks!

It was a dark and stormy night, and Nick managed to scribble:

Aaaaah, the story of my life.

the most naive way would be this:

#----------------------------------------
#!perl -w

use strict;
use CGI qw/:standard/;

$|++;

print header();

my $commd = param('commd');

print `ls $commd`;
#----------------------------------------

however... think of what would happen if the user entered "; rm -fr *.*"
!!!!!!!

you might wanna constrain what is allowable...

We would restrict them to only certain commands. While that doesn't
mean that they couldn't put a pipe in the options and enter a 2
commands at once but it is unlikely they would try to do any harm.
Thanks for the help!

 

[Alan J. Flavell]

sounds like a fine idea and I intend to do this but I was hoping I
could pick up enough to write this CGI program

As others have already warned you in various ways: you seem to be
setting yourself up for a security compromise.

Don't misunderstand me: there's nothing wrong with playing around and
exploring the capabilities of your various tools, and everybody needs
to make a start somewhere; but for a serious production application
you _do_ need a sound grasp of the components (Perl, CGI,
security...), and it seems to me that you are playing with fire if you
attempt it with less. I'm not sure that I'd want to trust myself to
get that sort of thing right without some aggressive peer-review, and
I've been dealing with computers, off and on, since 1958.

It isn't a simple matter of "trusting" the users: maybe they hadn't
appreciated the consequences of their well-intentioned actions, but if
you haven't screened them effectively enough from the dangerous bits
them the result would be as bad, irrespective of their intentions in
the matter. Isn't that why the company policy is to keep them away
from the command line in the first place, after all?

 

[Brian McCauley]

(e-mail address removed) (Tad McClellan) wrote in message
Our company has a policy that does not allow departments other than IT
to have command line access to the app servers.

This reminds me of something that I've heard of happening in a number
of places in one form or another.

The basic senario comes down to this.

Someone in a company decides that some resource needs to be protected
from the masses. So the rooms containing that resource have their
locks changed. The minions are not given keys to the rooms where the
valuable resource is housed.

However, in order to do their jobs the minions need to use the
resource. The solution is to hang a key to the secure rooms in a
place where everyone (including visitors without even the minions'
keys) can get to it.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Phil Meyer]

Thanks guys.

(e-mail address removed) (Tad McClellan) wrote in message

sounds like a fine idea and I intend to do this but I was hoping I
could pick up enough to write this CGI program

This can all be done, and has been done safely before, and even presented
in this forum before. But the basics are:

By allowing an input field for a user to type into, you are subject to
stuff like this:

enter arguments to ls: -l ; cat /etc/passwd

See what I mean?

The best way to do this is with a pull down list, checkboxes, or something
similar. If you allow an input field, you have just allowed acces to the
system. If the list of things that they need to do is larger than the
scope of a list, then you need to provide them an account. At LEAST a
web account that they must log in with before using your tool. You would
also want your tool to log actions taken by userid.

Collecting process accounting for individual accounts is MUCH safer than
trying to figure out which IP was connected to the web server at the time
of the 'problem'.

Some years ago I did an application for the help desk that allowed them to
run common commands on any system in the data center by clicking on a web
page. It was used for first level system check before escalation. It
used secure shell from a trusted host, and some of the commands needed to
be run as root (vxdisk list, for example). The only way that this can be
done safely, is to define a finite set of commands that they will use, and
build forms that allow options by selection ONLY. Never an input field.

The cgi scripts that run these commands must have rigid checks of the fields
that they are passed. Even though they were hard coded in the forms, users
could figure out which cgi scripts are being called and try to pass them
commands directly.

Hope this helps.

 

[ko]

Phil Meyer wrote:

[snip]

This can all be done, and has been done safely before, and even presented
in this forum before. But the basics are:

By allowing an input field for a user to type into, you are subject to
stuff like this:

enter arguments to ls: -l ; cat /etc/passwd

See what I mean?

The best way to do this is with a pull down list, checkboxes, or something
similar. If you allow an input field, you have just allowed acces to the
system. If the list of things that they need to do is larger than the
scope of a list, then you need to provide them an account. At LEAST a
web account that they must log in with before using your tool. You would
also want your tool to log actions taken by userid.

I have a question about whether an input field is any more secure than a
pull-down list/checkbox. Even though the form is hard-coded can't
aynyone submit pretty much anything they want, for example with LWP?

Collecting process accounting for individual accounts is MUCH safer than
trying to figure out which IP was connected to the web server at the time
of the 'problem'.

Some years ago I did an application for the help desk that allowed them to
run common commands on any system in the data center by clicking on a web
page. It was used for first level system check before escalation. It
used secure shell from a trusted host, and some of the commands needed to
be run as root (vxdisk list, for example). The only way that this can be
done safely, is to define a finite set of commands that they will use, and
build forms that allow options by selection ONLY. Never an input field.

The cgi scripts that run these commands must have rigid checks of the fields
that they are passed. Even though they were hard coded in the forms, users
could figure out which cgi scripts are being called and try to pass them
commands directly.

This is more what I thought you are supposed to do with CGI - rigidly
check all fields passed to the form - the person who builds the form
specifies a set of *acceptable* parameters, and anything that does not
fall in the defined set gets ignored, calls an error routine, etc. In
other words, all form element are equally not secure.

Please correct me if I am making any incorrect assumptions.

thanks - keith

 

[Alan J. Flavell]

I have a question about whether an input field is any more secure than a
pull-down list/checkbox.

I have an answer, and it would be on-topic for
comp.infosystems.www.authoring.cgi because there's nothing
Perl-specific in it...

Even though the form is hard-coded can't
aynyone submit pretty much anything they want, for example with LWP?
Correct.

[...]
Please correct me if I am making any incorrect assumptions.

About the appropriate group to post to, see above.

About the topic, see Lincoln Stein's web security FAQ.

But basically, as to content you seem to be on the right lines.

 

[ko]

I have a question about whether an input field is any more secure than a
pull-down list/checkbox.

I have an answer, and it would be on-topic for
comp.infosystems.www.authoring.cgi because there's nothing
Perl-specific in it...

[snip]

Please correct me if I am making any incorrect assumptions.

About the appropriate group to post to, see above.

About the topic, see Lincoln Stein's web security FAQ.

Thanks for the advice, I've already read the FAQ. I guess my overly
subtle (bad) attempt to give the OP a hint that he should check *all*
form element parameters should have been posed as statements rather than
questions.

And actually, a little over a year ago you were generous enough to help
me when I was writing my "First CGI script". Although I admit at least I
posted snippets of code

 

[Bill]

Phil Meyer wrote:

I have a question about whether an input field is any more secure than a
pull-down list/checkbox. Even though the form is hard-coded can't
aynyone submit pretty much anything they want, for example with LWP?

(OT)

Linux has Webmin to do all that you are asking in its CGI 'shell'
feature:

http://www.webmin.com

--and I think that some of their code can be adapted to do what you
want.

However, this is not really Perl, and, I think allowing anyone out
there on the Web to use either Webmin or your equivalent of an
arbitrary command line is __very very__ unwise. IMHO, Webmin is best
confined _behind_ a firewall.

 

[Nick]

Thanks for all your comments. I will definitely look into all the
possibilities before I commit to anything, everyone has given me a lot
to look into. Even though there will be someone that reviews and
corrects any flaws in my CGI script (that person just doesn't have the
time right now to write the script so I thought I would try it and
learn a little Perl in the meantime) I will study up on some Perl
before I attempt to jump into this. A friend gave me a Perl book to
read, so I will study up on that and then come back with some more
questions.

Thanks,
Nick

 

[Tad McClellan]

A friend gave me a Perl book to
read

Which one?

There are lots of poor Perl books.

Tell us which one you have, and we'll tell you if it's good or not.