Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 23 Sep 2013 17:16:43 -0400 (EDT)
Subject: Re: CVE-2013-5696: split needed

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]

> 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 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:

Certainly we would assign more CVEs if there are exploitable
vulnerabilities on a server that does not have the install/install.php

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

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

   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

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 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 ]
Version: GnuPG v1.4.14 (SunOS)


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.