[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 28 Nov 2014 20:06:16 -0500 (EST)
From: cve-assign@...re.org
To: covener@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request: "LuaAuthzProvider" in Apache HTTP Server mixes up arguments
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The short answer is yes: we do want security@...che.org 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
OK.
> 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJUeRtYAAoJEKllVAevmvmskfoH+wdugNTBI1lWKDWYmmxXY8ui
7aTef38WkXpoZUpci7ZEx1kaVqaz54BPwWULyYeksW/qmQ9b5GaO4UlTIRfmZT6V
/QOVZe6fA4Dehj7GmuvpwBBQuoYkybxzP/wQX3Bl+WW8ubO4I0DHJSm54m4PtXu+
C2Y8weSXE+oLYL1jpjryTSrAKrKNGpE6O1AujwmWrb8NJIYILSRq2bXt8hpRVmG3
XPHvd4BuHrMXukdGy5xwL2ZPXM53C/fjAK2OVnx3rjGuyiFwAPYtVjtSN3tixAjN
vtxljmnA+n8Afq1p/4vwCqwm9Syv7FGdlWFXbG6lS1erkVMBPMyw+I2VJkxgkGU=
=oebP
-----END PGP SIGNATURE-----
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.
