Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: CVE Request for Drupal Contributed Modules
From: Greg Knaddison <greg.knaddison () gmail com>
Date: Mon, 5 Nov 2012 09:56:08 -0700

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:


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]