Appendix E
CONTENTS
When installing Perl on Windows NT, it is very important to place
the perl.exe in any place other than your CGI bin. The details
of this problem and how to correct it are detailed here in an
announcement from Tom Christenson's Web site, which includes a
download of Latro, a program which you can use to check the security
of Perl on your NT server. For more information about this security
problem please check:
http://www.perl.com/perl/news/latro-announce.html
- Windows-NT web-servers
- NT web-servers with a PERL.EXE (or any other command language
interpreter executable) file in the \CGI-BIN\ directory.
- Other systems too(?)-Other systems are possibly affected by
this. For example: DOS PERL.EXE takes the -e switch too.
On the other hand I don't know of any DOS boxes running as
websites... ;-)
Where possible references to older documents (e-mail) are dated.
Starting at about mid December 1995 Tom Christiansen (of Perl
fame) posted a warning to one or more mailing lists devoted to
the Perl programming language. The warning was about the dangers
of placing your PERL.EXE file within your \CGI-BIN\ directory
on a Windows-NT web-server. This is a very unsafe thing to do!
You can safely run cgi-bin scripts written in Perl on an NT Web
server. There are, in fact, several secure ways to do so. This
document describes a few of the things you can do to ensure system
security. This is not a document about the programming strategies
required to write secure cgi-bin perl scripts in general. Please
note carefully that while this document focuses on PERL.EXE, it
is true that putting any <INTERPRETER>.EXE into your \CGI-BIN\
will open your webserver up to trouble, big trouble. This includes
BASH.EXE, CSH.EXE, KSH.EXE, JAVA.EXE, PYTHON.EXE, SH.EXE, TCLSH.EXE,
TCSH.EXE, VCL.EXE, WISH.EXE, ..., etc. This potential trouble
is due in part to the cgi-bin mechanism (which pass arguments
to an interpreter on command line or via environment variables).
If the whole interpreter is sitting in \CGI-BIN\, then any commands
at all may be passed to it for execution. In other words, if you
do not allow your system or your webserver software to determine
something about what arguments it takes and how it handles them
(i.e., a cgi-bin script that talks to the interpreter only if
it is safe to do so) then the whole Internet can talk to your
command interpreter and feed it evil commands like DELETE *.*;
YES;.
How'd you like to let anyone anywhere run any program they feel
like on your system, even sending you new ones of their own devising?
Sound frightening? Well, that's what's going on out there.
Despite months of lobbying corporations, individuals, and the
net at large about the perl.exe?FMH.pl problem, it continues to
get worse. In the spirit of the Satan network checker, here's
something that will find out whether you have the problem. It's
called Latro, a program anyone can use to run any program they
feel like on any system so unfortunate as to have ignored those
warnings. If I hadn't written it, someone else would have. You
may argue that I've just given a lockpicking kit to the unwashed
masses. Perhaps this is so, but far better that everyone should
have the same resources at their disposal than that merely the
thieves should have them. This way at least the locks might get
fixed.
Already several people have posted to USENET about how one can
use Alta Vista to find these sites. It's only a matter of time
before these sites get, um, visited. Hopefully someone will construct
a list of these and notify them. This is, of course, just a fraction
of the vulnerable sites. Let's clean it up out there, guys. Nefarious
users could even ship over their own PC binaries and run them
on your system, which means that if you aren't careful, they might
do something useful like forcibly upgrade you to Linux. Of course,
then the perl.exe?FMH.pl travesty magically goes away, along with
a whole lot of other problems. :-)
NOTE |
This problem probably affects only amateur and/or commercial machines running those cursèd spawn of CP/M that Microsoft (and no one else) calls operating systems. Professional software development systems like Unix and Plan9 should be largely
unaffected. Paradoxically enough, Apple systems running their native systems should also be ok because the setup is so different. But please never underestimate the power of human stupidity when it comes to using technology they don't understand. There are
also loads of sites out there with other interpreters than Perl in their cgi-bins, including shells, tcl, python, etc. This has got to stop.
|
CERT has been notified of the issue, and has released a report
about the problem.
latrodectus cyberneticus-probe web for insecure Perl installations
Synopsis
Via command line arguments:
latro host1 //host2/bincgi //host3/bincgi/badperl
or via STDIN:
sed 's/ .*//' access_log | sort -u | latro
Latro is designed to probe whether the site or sites you control
have been compromised by the insanely idiotic practice of placing
a perl executable in the cgi-bin. If you have ever seen anyone
post a URL like:
http://dummy.org/cgi-bin/perl.exe?FMH.pl
then you know they have the problem. This is pathetically pervasive
amongst (horrifically mismanaged) sub-Unix web sites.
Robert Heinlein once wrote:
Stupidity cannot be cured with money, or through education, or
by legislation. Stupidity is not a sin, the victim can't help
being stupid. But stupidity is the only universal capital crime;
the sentence is death, there is no appeal, and execution is carried
out automatically and without pity.
Consider this program such execution, or at least the threat thereof.
You can do very evil things with this program. Very evil things.
You can execute ANYTHING YOU WANT on their site, even sending
over your own binaries instead of just Perl code. Please don't
do anything (too) wicked. When you find such sites, please do
the responsible and professional thing and mail their cluefully
challenged webmaster about the problem. My goal with this program
is to shake up the web a little bit now lest a real poison spider
should someday rip it to shreds and blame Perl. It's not Perl's
fault. It's the idiocy of the PC web sites-and the vendors and
docs that tell them to do this ineffably idiotic and evil thing.