> Randolf Richardson wrote:
> >> Hi Folks,
> >>
> >> I'm reasonably certain that this is just a misconfigured mod_perl server 
> >> on my part, but I can't seem to find a solution for it.
> >>
> >> We are currently running ModPerl::Registry to serve legacy CGI code.  
> >> Now, consider the following URL, with an embedded newline:
> >>
> >> http://www.mysite.com/cgi-bin/search.cgi%0d%0a
> >>
> >> Since we obviously don't have a CGI file named with a trailing newline 
> >> character, I would expect apache to return a 404 Not Found.  However, 
> >> apache happily hands the URL off to mod_perl, which attempts to stat 
> >> search.cgi(newline), and fails with:
> >>     
> >
> >     ModPerl is correct if the filename supplied doesn't exist (which you 
> > seem to be implying that it doesn't), and what's really nice is that 
> > it's informing you of the likely problem with the filename.
> >
> >     The URL that people should be using should just end with 
> > "search.cgi" and if they're typing this in and adding "%0d%0a" to the 
> > end of it then they deserve to receive a 404 Not Found error.
> I agree completely!  Unfortunately, that's not what's happening.  We're 
> not getting a 404, we're getting a 500 Internal Server Error.  I guess 
> that is because perl is throwing an untrapped exception when it sees the 
> filename-with-newline.  But yes, my issue is that such a request 
> generates a 500. I feel that mod_perl should be returning 404 in this 
> case, since the file is indeed not found.
> 
> Generally, these kinds of requests are attempts at HTTP header-injection 
> or similar attacks.  So I'm under no obligation to be helpful to them :)
> 
> Thoughts?

        If they're not being generated by users, then I wouldn't worry about 
it aside from taking the usual security precautions (updates, code 
reviews, etc.).

        If there is an issue with heavy bandwidth consumption, then I'd look 
at blocking the offending IPs (and look into the various RBL modules 
to automate prevention), and in which case the response of a status 
500 is far better than sending back an HTML page to some mindless bot 
or dark hacker who doesn't care (and that could even consume other 
resources due to querying SQL servers and whatnot).

        You could ask about those types of malformed URIs in Apache HTTPd 
server mailing lists or on irc.freenode.net to find out if there are 
other options if it continues to bother you.  I typically see more 
weird stuff (aside from the usual PHP script kiddie admin hacks even 
though I don't have PHP installed, heheh) in my server error logs on 
the busier web sites, and the fact that they're handled as errors is 
already a fairly good indication that the server handled the requests 
in the right way.

        Good luck.  I wish I could be more help.

[End of reply.]

> Thanks,
> MAC
> 
> >     <snip>
> >
> >
> >     I hope this helps.
> >
> > [End of reply.]
> >
> >   
> >> [Wed Feb 13 16:27:33 2013] [error] [client 192.168.254.21] Unsuccessful 
> >> stat on filename containing newline at 
> >> /usr/local/lib64/perl5/ModPerl/RegistryCooker.pm line 787.\n
> >>
> >> ... which in turn results in a 500 Server Error.
> >>
> >> Trying a similar URL with a php file on the same server correctly 
> >> returns a 404.  Also, requesting a file like 
> >> /cgi-bin/this_file_does_not_exist.cgi correctly returns a 404.  However, 
> >> /cgi-bin/this_file_does_not_exist.cgi%0d%0a returns 500.
> >>
> >> What can / should I do to get the "correct" behaviour out of mod_perl?  
> >> I could probably do something with a mod_rewrite RewriteRule to strip 
> >> newlines, but I feel like I shouldn't have to run every request through 
> >> a RewriteRule.  I could also accept if mod_perl treated this as a 
> >> warning, but that's not the case here.
> >>
> >> Here is line 787 of RegistryCooker.pm, btw:
> >>
> >> 783: # XXX: should go away when finfo() is ported to 2.0 (don't want to
> >> 784: # depend on compat.pm)
> >> 785: sub Apache2::RequestRec::my_finfo {
> >> 786:     my $r = shift;
> >> 787:     stat $r->filename;
> >> 788:     \*_;
> >> 789: }
> >>
> >> Thoughts?
> >>
> >> Thanks!
> >> Michael
> >>     
> >
> >
> >   
> 


Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/


Reply via email to