Re: CVE Request for Drupal Contributed Modules

[Greg Knaddison <greg.knaddison () gmail com>]

Responses inline below.

Also cc'ing Forest Monsen (a member of the Drupal Security Team) who
will be helping with the CVE process for us from now on.

On Wed, Oct 31, 2012 at 9:02 PM, Steven M. Christey
<coley () rcf-smtp mitre org> wrote:
> Joshua and others on the Drupal team,
>
> It appears that the following followup questions by Kurt Seifried were
> missed during some of the confusion over contacts and email addresses for
> Drupal-related security issues.
>
> Please respond to the comments in this email, as it supercedes Kurt's email
> from October 7.
>
>
> On Sun, 7 Oct 2012, Kurt Seifried wrote:
>
> > > Multiple Vulnerabilities: http://drupal.org/node/1719548 |
> > > SA-CONTRIB-2012-125 - Chaos tool suite (ctools) - Local File
> > > Inclusion http://drupal.org/node/1719548 | SA-CONTRIB-2012-125 -
> > > Chaos tool suite (ctools) - Cross Site Scripting (XSS)
> >
> >
> > This sounds like a single issue with two possible outcomes?
> >
> > The module doesn't sufficiently validate css import statements to
> > confirm they only include css content appropriate to show to end
> > users. This could allow a malicious user to add sensitive content from
> > the site (e.g. settings.php) exposing that sensitive content to
> > visitors of the page. It could also be used to execute a Cross Site
> > Scripting attack.
> >
> > Links to the code commits fixing this would be helpful.

I believe this is the commit
http://drupalcode.org/project/ctools.git/commit/863e53e

I believe it is the case that XSS is one example of how to exploit the
issue but that Local File Inclusion is the fundamental problem. The
local file inclusion is just into a CSS context so it's not a way, for
example, to execute arbitrary PHP. However it could be used to read
any file on the server and display the contents inside of CSS (if
Drupal's css aggregation feature is enabled). So, someone could use
this to read the database credentials, for example. That might still
not be enough to compromise the server depending on mysql access
settings, firewalls etc.

> Your answer to this question will help determine whether we have one CVE or
> two.
>
>
> > > http://drupal.org/node/1732946 | SA-CONTRIB-2012-126 - Hotblocks -
> > > Cross Site Scripting (XSS) and Denial of Service (DoS)
> >
> >
> > This is a multiple CVE issue?
>
>
> Kurt - we investigated the advisory and it's pretty clear that the two are
> distinct, so we assigned the following CVEs (Drupal people, please take
> note):
>
> CVE-2012-5704 - DoS (infinite loop with self-referencing block)
> CVE-2012-5705 - XSS

Advisory updated with these numbers http://drupal.org/node/1732946

> > > Multiple Vulnerabilities: http://drupal.org/node/1762220 |
> > > SA-CONTRIB-2012-130 - Jstool - Access Bypass
> > > http://drupal.org/node/1762220 | SA-CONTRIB-2012-130 - Jstool -
> > > Arbitrary code inclusion
> >
> >
> > The description/vulns don't seem to match up on this one. Can you clarify?
> >
> > The module does not protect its menu paths, which contain sensitive
> > information about all javascript files on the site and their contents.
> > The module does not validate filenames which can lead to potential
> > read/write access to arbitrary files on the server.
> >
> > Links to the code commits fixing this would be helpful.

Attached is the patch the maintainer provided for this issue -
jstool-final-77678-23.patch I'm not immediately sure which commit in
git corresponds to this.

I believe there are distinct issues here:
* The ability to read/write to arbitrary files
* The ability to identify and read all Javascript files of the site -
this is somewhat by design of Javascript, but the team member working
on this issue felt that having direct access to read all files in one
place would be useful to an attacker enough that it deserved mention.
For example: It could be helpful to an attacker to see the source code
of the Javascript for Ajax features that are admin only.


> Drupal team - if these both have the same root cause, such as a directory
> traversal issue, then they would receive one CVE since they are the same
> type of issue - even if there are different impacts.  Otherwise, two CVEs
> might be needed.
>
> > > http://drupal.org/node/1762482 | SA-CONTRIB-2012-133 - Taxonomy
> > > Image - Cross Site Scripting (XSS) & Arbitrary PHP code execution
> >
> > So this is the same root issue, not filtering file uploads allowing an
> > attacker to upload arbitrary stuff (including PHP code), the outcome
> > of which could be PHP code execution, or XSS (or other things I
> > suppose like DoS, CSRF, etc.)?
>
>
> This is the same basic issue as the last one.  If there's one root cause in
> which file uploads aren't prevented when they should, then they might
> receive only one CVE.
>
> (Basically, if a user X is intentionally allowed to do action Y, but a
> vulnerability allows somebody to become X - then we don't assign a separate
> CVE ID for Y.)

Yes, this is fundamentally an "upload arbitrary stuff" issue.

> Thanks,
> Steve

Thank you for your attention to detail!  :)

Regards,
Greg

Attachment: jstool-final-77678-23.patch
Description: