Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 28 Nov 2014 20:06:16 -0500 (EST)
Subject: Re: CVE Request: "LuaAuthzProvider" in Apache HTTP Server mixes up arguments

Hash: SHA1

The short answer is yes: we do want to allocate a
CVE if they agree with you that the issue is a vulnerability. MITRE
won't be assigning a CVE ID, and thus there won't be a duplicate.

> No, it does not require LuaAuthzProvider in the wrong context


> If you did this twice with different arguments

We don't know what "you" means here. For example, maybe "you" can only
mean the administrator. Your first message said "in httpd.conf." Your
second message said 'wherever "Require" is valid (everywhere).' If an
unprivileged user can create a "Require my-provider guest" line for
directory A within a .htaccess file, and this has the effect of
overriding a "Require my-provider admins-only" line for directory B
within httpd.conf, then certainly there's a vulnerability.

If both Require lines must be entered in httpd.conf by the
administrator, then there may or may not be a vulnerability. We think
there's a good chance that there's a vulnerability, because ability to
have both a "Require my-provider admins-only" line and a "Require
my-provider guest" line is a realistic interpretation of the
documentation. It is also an ability that administrators would want to
have. However, LuaAuthzProvider is "Status: Experimental." A vendor
might have a different view on what is a vulnerability in experimental
code versus what is a vulnerability in non-experimental code. For
example, if enabling the experimental code allows an unconditional
code-execution attack with crafted input, that's one class of problem.
If it happens to be very easy for the administrator to configure the
experimental code insecurely, because the vendor hasn't tested many
use cases beyond what is explicitly shown in the documentation,
that's a different class of problem. We feel the LuaAuthzProvider case
is closer to the latter. Here, the easiest and best way to resolve the
various possibilities is for the Apache Software Foundation to confirm
your vulnerability finding and allocate the CVE.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ