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

A serious security problem with 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 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 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 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 '' module that 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 where you can get a copy of 3.01




  • Comment on A serious security problem with 3.01?

Replies are listed 'Best First'.
Re: A serious security problem with 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 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 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 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 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 uses In 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) is a bit worrying as *some* people still insist on hand installs and 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).




Re: A serious security problem with 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, 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 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.




        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 yourself by using the

        Anyway, I've decided to just use a 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 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 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 :))


Re: A serious security problem with 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 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 3.01 with a hand install and a fully functional one with a regular install before I pester Lincoln.




(crazyinsomniac) Re: A serious security problem with 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; } }

    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?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://95702]
Approved by root
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
Find Nodes?
    Voting Booth?

    No recent polls found