Without going through the way nginx parses an incoming request, I’m
unsure
if nginx isn’t vulnerable to this, because of the availability to grab
the
value of a GET parameter via http://wiki.nginx.org/HttpCoreModule#.24arg_PARAMETER. My hope is that
especially if an $arg_PARAMETER isn’t used in the config, it is not
vulnerable because it wouldn’t even attempt to parse the parameters, but
I
can’t be sure.
Thank you for the confirmation - I read through the parts of code in
question but wanted to get a second opinion.
How about the lua and/or the perl modules? It looks as if they are
using the nginx functions?
The current released versions of ngx_lua does have this vulnerability
in its ngx.req.get_uri_args() and ngx.req.get_post_args() functions.
I’ve already worked out a patch for these two functions in ngx_lua’s
git max-args branch here:
With this patch, both of these functions will only parse 100 query
args at most. And one can specify a custom maximum number of args
parsed with an optional function argument (default to 100) and
enforcing unlimited parsing by specifying a zero number.
This patch (as well as this branch) will be merged into the master
branch in 3 Jan.
I’ve already worked out a patch for these two functions in ngx_lua’s
branch in 3 Jan.
It would probably be a good idea at that point, to finally make a
release of v0.3.1 of the ngx_lua module as with about 45 “Release
Candidates”, it must already hold some record
Without going through the way nginx parses an incoming request, I’m unsure
if nginx isn’t vulnerable to this, because of the availability to grab the
value of a GET parameter
viahttp://wiki.nginx.org/HttpCoreModule#.24arg_PARAMETER. My hope is that
especially if an $arg_PARAMETER isn’t used in the config, it is not
vulnerable because it wouldn’t even attempt to parse the parameters, but I
can’t be sure.
Well, the $arg_PARAMETER variable is not implemented with hash tables
at all It scans the URI query string at every invocation
On Sun, Jan 01, 2012 at 05:31:46PM +0300, Nginx U. wrote:
I’ve already worked out a patch for these two functions in ngx_lua’s
branch in 3 Jan.
It would probably be a good idea at that point, to finally make a
release of v0.3.1 of the ngx_lua module as with about 45 “Release
Candidates”, it must already hold some record