---------- Forwarded message ----------
From: Brian Rectanus <brectanu@...>
Date: Jul 21, 2006 5:38 PM
Subject: Re: [mod-security-users] SERVER_PROTOCOL issues
To: Ivan Ristic <ivan.ristic@...>
OK, have some time to look at this further...
On 7/20/06, Ivan Ristic <ivan.ristic@...> wrote:
> On 7/20/06, Brian Rectanus <brectanu@...> wrote:
> > Hello,
> > I am seeing some interesting requests that are getting caught by this rule:
> > SecFilterSelective SERVER_PROTOCOL "!^HTTP/(0\.9|1\.0|1\.1)$"
> > "deny,status:403,msg:'Invalid HTTP protocol'"
> > The problem seems to be that a GET request that violates RFC seems to
> > be either parsed or handled by apache differently than mod_security
> > for SERVER_PROTOCOL given a request like this (older browser flaw, I
> > think)...
> > GET /foo?dstamp=07/19/0606:14 PM HTTP/1.1
> > ...
> > However, mod_security seems to get a mis-parsed request like this (as
> > the above rule fires):
> > SCRIPT_NAME: '/foo'
> > QUERY_STRING: 'dstamp=07/19/0606:14'
> > SERVER_PROTOCOL: 'PM HTTP/1.1'
> That should be correct. ModSecurity is not parsing the request line -
> it simply uses the values produced by Apache. (From memory, Apache
> ignores the name of the protocol but looks at the numbers.) The real
> mistery in your case is how does the CGI end up with a different
> value. Is it a simple CGI that outputs environment variables?
I had tested with stock printenv. It loos like what happens (and why
it *appears* to work) is that the backend app server is redirecting to
the truncated URI: /foo?dstamp=07/19/0606:14 if the request is allowed
to pass through. So, the cgi output looks correct if you don't see
the redirect. Seems like a better approach would be for it to either
fail or quote the spaces instead of corrupting data.
Also, server/protocol.c parses the protocol version by looking for it
being 8 bytes, then doing a quick match, or if not 8 bytes (as in this
case), sscanf(r->protocol, "%4s/%u.%u", http, &major, &minor). So,
httpd gets the protocol data and can parse the request, but it does
not alter r->protocol with the parsed version for later use and we see
'PM HTTP/1.1'. I am going to block it anyhow (to prevent data
corruption), but still very interteresting.
Would you consider this a bug in httpd? I think I do considering it
is allowing data corruption without any errors/warning. I may report
it as such and see what happens.
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall