Date: Mon, 23 Sep 2013 17:16:43 -0400 (EDT) From: cve-assign@...re.org To: kseifried@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, geissert@...ian.org, jmd@...epnet.net, moyo@...epnet.net, info@...ridge.com Subject: Re: CVE-2013-5696: split needed -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On 09/20/2013 02:27 AM, Raphael Geissert wrote: >> GLPI 0.84.2 fixes a few security issues , for which >> CVE-2013-5696 was assigned. However, from the bug tracker it is >> clear that there are multiple issues: >> * SQL Injection * PHP Code Execution * CSRF (seems that it is the >> vector for the SQL injection) >> So, it looks like the CVE id was originally assigned to the CSRF >> vulnerability, then reused for the SQL injections, and the code >> execution vulns. were just added to the same bug report but it is >> completely independent and not covered by the existing CVE id. >> https://forge.indepnet.net/issues/4480 > I assume this was assigned by Mitre, probably best to have them do the > split. CVE-2013-5696 was assigned by MITRE, but it was not originally assigned for CSRF. The "Associated revisions" column of https://forge.indepnet.net/issues/4480 does show different types of changes to different parts of the code. As far as we can tell, install/install.php is part of the distributed software but is not intended to be part of the deployed product. In 0.84.2, it seems that a warning to remove install/install.php is displayed to a privileged user every time that the showMyView function is executed in a privileged user's session. The root cause of the reported exploitation outcomes is that install/install.php is accessible with the unintended functionality of reaching the installation steps after an installation has been completed. There is one CVE for that: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5696 Certainly we would assign more CVEs if there are exploitable vulnerabilities on a server that does not have the install/install.php file. Other than that, it ultimately reduces to the general problem of CVE assignments for web-based installations of web applications, and how to decide whether the available behavior crosses privilege boundaries. In many common installation processes for web applications, the software distribution is extracted into a web-server directory, and the entire remainder of the installation process starts with an unauthenticated web session from an arbitrary client machine. The amount of time after extracting files until a legitimate user starts that web session could realistically range from seconds to years. From an absolutist perspective, this is always wrong and should always have a CVE assignment, because it offers no protection against an initial installation by an unauthorized person. In practice, we often don't assign CVEs for that. We usually consider it a valid usability/security tradeoff. One principal exception is that we do assign a CVE if the extracted or installed web application allows remote code execution -- even if it's intentional remote code execution by an admin. In other words, the usability/security tradeoff can be invalidated by the nature of the application. The current case is similar. CVE-2013-5696 is the ID associated with the root cause of the problem that was actually reported by Navixia. At least one other problem was strongly implied but not clearly disclosed. Specifically, if no legitimate user ever ran the GLPI installation procedure, install/install.php will exist and can be used for PHP code injection. So, we think we should assign a second CVE for: GLPI before 0.84.2, when install/install.php exists because of no installation or an incorrect installation, allows remote attackers to execute arbitrary PHP code via an update_1 action to install/install.php with a crafted databasename parameter, as demonstrated by placing the PHP code after a ';} sequence, followed by a direct request to index.php. with an additional reference of https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/http/glpi_install_rce.rb Here, "an incorrect installation" is intended to cover all of the possibilities: the legitimate user forgot to delete install/install.php, the legitimate user planned to delete install/install.php but the attack occurred before the deletion, etc. We're not sure if there's anything else important enough that more than two CVEs are really needed. We'll probably wait for the https://www.htbridge.com/advisory/HTB23173 update that's scheduled for October 2. Again, web-based installations of web applications are often inherently characterized by missing authentication, so the cutoff for what qualifies for a CVE is a bit different than in normal cases of already-installed products. - -- 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) iQEcBAEBAgAGBQJSQK3XAAoJEKllVAevmvmsbBgH/1HlyQynqKj7mazdxlXarQXv GY++bjB0mH1+umPcGfafDtF+ZdWMis2RzFGDftXxCLy5EVhvp3lHuxg7Pxf0uIzT lRHlU1mf92NY2i2KTI+juP0bHvc+erPXwNJk6GEQfTlH/XqxPUyX/QrjaaUqGK8/ 008bFC+HkQAwEbsLvzh+WniMyE/Kg3+WPx8we311jNODl+zLr59Pf5I7AHectn0Z PkHm0L3oAxPnsaluxnyvz351OZRjhz2CFndOIGZJ3KegGCRdz6soSBh4CsR4lBEE 9pS3RX7+fCegpUHzzo4Q5bGydqy/sdFCXVvr67c7tY8m6zOpJN44DGxuIuTBsd4= =hgB3 -----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.