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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ