[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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 [1], for which
>> CVE-2013-5696 was assigned. However, from the bug tracker[2] 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.
>> [2]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.
