[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Nov 2014 17:23:24 -0500
From: Eric Covener <covener@...il.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE Request: "LuaAuthzProvider" in Apache HTTP Server mixes up arguments
On Fri, Nov 28, 2014 at 3:36 PM, <cve-assign@...re.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=57204
>
> We're not sure that this crosses privilege boundaries.
> http://httpd.apache.org/docs/2.4/mod/mod_lua.html#luaauthzprovider
> says
>
> Context: server config
>
> Apparently you're trying to use it in a directory context and finding
> that it doesn't work correctly. At least in theory, this could have
> been resolved by reporting an error when LuaAuthzProvider is found in
> a directory context, rather than by using the actual
> https://issues.apache.org/bugzilla/show_bug.cgi?id=57204#c2 approach
> to add the functionality.
>
> So, it may be reasonable to interpret this as a non-security bug that
> occurs when an administrator intentionally enters httpd.conf content
> that is, according to the documentation, invalid.
No, it does not require LuaAuthzProvider in the wrong context to
produce the vulnerability with the parameters.
When LuaAuthzProvider appears only in server/vhost context it defines
an authorization provider -- say "my-provider".
You can then use "my-provider" wherever "Require" is valid (everywhere).
Wherever you use it with "Require my-provider", you can also pass an
argument. For example if your provider did the same task as
mod_authz_goupfile you might pass the path of a group file, or the
name of a group to lookup (or both with some delimieter).
If you did this twice with different arguments, the script in each
context receives the last-defined argument.
So if you configure and tested "Require my-provider admins-only", then
configured and tested "Require my-provider guest" in another context,
you'd end up with mixed-up args passed to the first provider.
> We notice that
> https://issues.apache.org/bugzilla/show_bug.cgi?id=57204#c4 says
> "waiting to see if a CVE should be assigned." The usual process for
> CVE assignments for Apache Software Foundation products is:
>
> http://www.apache.org/security/committers.html
>
> Here, we realize that the issue was sent directly to the oss-security
> list, but MITRE doesn't have enough information to make a final
> decision. The Apache Software Foundation can decide whether the
> erroneous LuaAuthzProvider handling is a vulnerability from the
> perspective of their security policy.
It was first disclosed publicly in an online comment in the httpd
manual. Since it did not seem very sensitive, I copied it to a public
bugzilla before asking for a CVE privately from security@...che.org.
Since it had already been public (twice), the security team said I
should initiate it via oss-security@ to avoid duplicates.
If you'd like security@...che.org to allocate the CVE despite it
having been discussed publicly, please confrm here. Thanks.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
