0
votes

First, as a background I am trying to encrypt data we have on the server when a new entity is made. This is on a legacy system which originated as a Perl CGI system, and has a separate portion which is PHP. The Perl part creates the groups, the PHP was later implemented to encrypt it.

I am trying to execute the PHP encryption script from a Perl CGI file. I have tried using:

exec("/path/to/file arg1 arg2")
system("/path/to/file arg1 arg2")
backtick operator /path/to/file arg1 arg2
open ("/path/to/file arg1 arg2 |)

I have also tried pointing directly to /bin/php and passing the file as an argument with each case. The only things I have had happen so far are:

  1. Printing the output of exec/system... produces the Perl file (not even the php file) as text, which I haven't seen any mention of this happening anywhere else, but all I've seen is Perl, not CGI and Perl together.
  2. No data. If I output $! from Perl I get an illegal seek error when using system, but the others leave it blank. All of them return 0 as if the exec/system/... has run, but nothing server side has changed.

From what I have read online I think that CGI may be running in some form of a "protected" mode which disables the exec/system/open/backtick commands on certain files, but am not certain that is the issue. As far as I can tell though, there is no indication of permission being restricted. If anyone has any insights that is much appreciated. If you need anymore information, let me know.

1

1 Answers

5
votes

A few notes:

  • Show us actual, mimimal and complete test programs along with their output so we can see what you are doing.

  • system shares its filehandles with the parent program, so if the external program sends something to STDOUT, that's where it's going. If that's before you send your CGI headers, then things will get messed up.

  • backticks will capture standard output, but not standard error. Stuff might still go to an error log.

  • exec turns your program into some other program. That is, your Perl program does some setup and then becomes the thing that you exec, then never comes back (unless things fail).

Some things to help with debugging:

  • Make a small CGI program that simply calls another program you know that should work, such as date or something similar. Verify that you can do that much.
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
my $rc = system '/bin/date';
print "result was <$rc>";
  • Then, run php to show its version. Verify that you can run php.
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
my $rc = system '/usr/bin/php', '-v';
print "result was <$rc>";
  • Slowly add to the complexity. Find out where things stop working.

If your arguments to PHP come from user input, consider using taint checking and careful cleansing (perlsec). Notice I use the list version of system so the shell doesn't get a chance to interpret metacharacters.