Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

A serious security problem with CGI.pm 3.01?

by tachyon (Chancellor)
on Jul 11, 2001 at 18:45 UTC ( [id://95702]=perlquestion: print w/replies, xml ) Need Help??

tachyon has asked for the wisdom of the Perl Monks concerning the following question:

Thathom started a discussion on the chatterbox about why CGI.pm seemed to be allowing any size file to upload. Sure you say, he didn't set $POST_MAX. Well he did actually. The problem is that in his version of CGI.pm the initialise_globals() sub seems to be missing. All references to $POST_MAX outside the pod are missing. OK so it's been edited.

The problem is that he downloaded it from Lincoln Stein's website! I just downloaded a copy of 3.01 - in the CGI.pm file there is no reference to $POST_MAX anywhere outside the pod (at least according to my editor's find function). The initialise_globals() sub present in 2.74 (which I have on this box) is absent in 3.01. This would appear to be a significant security problem as it opens this version up to denial of service attacks. Has this been moved to an external library for some reason? I have looked in the new 'object.pm' module that CGI.pm now uses and it is not there. Am I mistaken or is this a real problem? Is it only a problem if a proper install is not made (I think that a cut and paste method was used :-(

Here is the link to Lincoln site http://stein.cshl.org/WWW/software/CGI/cgi_docs.html#download where you can get a copy of CGI.pm 3.01

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

  • Comment on A serious security problem with CGI.pm 3.01?

Replies are listed 'Best First'.
Re: A serious security problem with CGI.pm 3.01?
by arturo (Vicar) on Jul 11, 2001 at 19:25 UTC

    Hmm, I found this snippet of code, which can be found in the init sub in the raw CGI.pm you can download from there:

    METHOD: { # avoid unreasonably large postings if (($POST_MAX > 0) && ($content_length > $POST_MAX)) { $self->cgi_error("413 Request entity too large"); last METHOD; }

    So it's not as if the POST_MAX functionality has been stripped from CGI.pm 3.01 in all versions. Maybe there's a glitch in the tarball? (which I'm assuming you used).

    I'd be interested to see what happens if the module is in fact *installed* rather than (as appears to have been the case here) just taking the CGI.pm file from the tarball and placing it in the same directory as the CGI script. After all, you gotta leave something for Makefile.PL to do =)

    update : here's a thought. Try :

    grep 'POST_MAX' *

    in the directory where you unpacked the tarball.

    perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); +$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth +er_name\n"'

      Yes I downloaded the tarball - the CGI.pm contained within does not have this METHOD. Nor does it have the string $content_length. As noted the only place $POST_MAX appears is in the pod with a reference to the missing initialise_globals() sub.

      iakobski points out that Object.pm uses State.pm. In State.pm you can find the missing references to $POST_MAX. It must therfore be an installation problem. The pod has just not been updated yet to reflect the new postioning of $POST_MAX. The fact that you seem to be able to do a hand install that gives a functioning (sort of) CGI.pm is a bit worrying as *some* people still insist on hand installs and CGI.pm is so popular this is bound to happen. Oh well what do you expect if you don't read the instructions!

      I was having nightmares as I have been pestering my sysadmin to upgrade from 2.75 to 3.01 as the upload method is broken on our 2.75 (you just have to get your file handle the old way).

      cheers

      tachyon

      s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Re: A serious security problem with CGI.pm 3.01?
by rrwo (Friar) on Jul 11, 2001 at 19:56 UTC

    Did you at least contact Lincoln Stein (the author) about this?

      No, I have not emailed Lincoln rrwo. Unfortunately I have internet connectivity at work but no outgoing email :-( I presumed that there was no way an oversight this big could have occurred so put it up for discussion. It got moved here by one of the editors. It seems the problem is a bad (hand) install as noted above. Still cause for concern as the hand install seems to run (kinda)!

      I am a convert of CGI.pm, although as I don't use the HTML display part feel (like others) that it might be better split into two modules - a CGI data parsing part and an HTML generating part. Yes, I know there are alternatives but this module is the *gold standard* that comes with Perl so it is concerning than someone seems to have devised a way to silently break it through a bad install. Some code at the begining of the module like:

      die "Bad install detected" unless module_checks_out();

      might be nice if this is indeed the case. It would be trivial to include some code that adds a __DATA__ element that CGI.pm could have added to it during a proper install and read before running via the module_checks_out() sub postulated above. The speed penalty would be negligible as no system call would be required, just a read off the <DATA> filehandle.

      cheers

      tachyon

      s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

        Im sorry for starting a big problem with the cgi thing :)
        So it wasnt me being thick after all?
        I thought maybe you had to create the cgi.pm yourself by using the makefile.pl.

        Anyway, I've decided to just use a CGI.pm that arturo advised. (tan-ku)
        Seems to be working ok now.
        Why do things have to be so complex?, to be honest I don't like using the CGI.pm as I like making code myself and planning where it goes, how i get it etc. Im one of these people who likes to know i did it all, typed every character of it.
        Its as though the CGI.pm interupts the way i should think. (even though im sure it does everything perfectly well). I know I'll never use the HTML part of it either. Mind you, the things I'm creating arent massive as Im a learner. Im sure its more useful for programmers designing MASSIVE systems... saves typing as much. (or maybe its just for lazy people.. or even people who don't know html).

        Im talking arse aren't I?,
        I'll stop now :))

        ThAtH0M

Re: A serious security problem with CGI.pm 3.01?
by $code or die (Deacon) on Jul 12, 2001 at 03:49 UTC
    According to the readme for version 3.03, version 3.* of CGI is in alpha. This probably means that it shouldn't be used in production code. I don't think that it is wise to upgrade yet until it's fully tested.

    I suggest contacting Lincoln Stein by email and let him know.

    Error: Keyboard not attached. Press F1 to continue.

      Thanks $code_or_die, didn't know that. Old saying "No read manual, no have clue". That probably explains my sysadmins reluctance to install it! I just worry about a broken method, he gets to worry about the whole system.

      I'm sure the problem just relates to a hand install but it seems odd to have moved this particular code into a module to me, especially as it is important. But then again, I have never found the coding style in CGI.pm all that transparent. I will give it a day or two to see what gets added here and would like to see for myself if you can generate a functional but broken CGI.pm 3.01 with a hand install and a fully functional one with a regular install before I pester Lincoln.

      cheers

      tachyon

      s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

(crazyinsomniac) Re: A serious security problem with CGI.pm 3.01?
by crazyinsomniac (Prior) on Aug 04, 2001 at 16:56 UTC
    Why not do the dirty work yourself? Something like:
    #!/usr/bin/perl -w BEGIN # run before anything { my $POST_MAX = -1; my $CL = defined($ENV{'CONTENT_LENGTH'}) ? $ENV{'CONTENT_LENGTH'} : +0; if(($POST_MAX > 0) and ($CL > $POST_MAX)) { print "Content-Type: text/plain\n", "Status: 413\n\n", "413 Request entity too large"; exit; } }

     
    ___crazyinsomniac_______________________________________
    Disclaimer: Don't blame. It came from inside the void

    perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://95702]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (7)
As of 2024-04-18 21:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found