Identifying Perspective Issues in CWE

[Steven M. Christey-2]

All,

As we've been developing the natural hierarchy, we've started paying
more attention to the problem in which CWE supports multiple different
perspectives.  This is posing challenges for developing the natural
hierarchy, but it is also reflected in how tools map to CWE.

The purpose of this message is to raise awareness about these
challenges, and to solicit feedback from CWE researchers on ways of
handling these.

Here's a live example to work with.  A fairly well-known research team
called Security Reason recently released an advisory that maps to a
CWE number:

  CVE-2008-2665
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2665

  PHP 5.2.6 posix_access() (posix ext) safe_mode bypass
  URL:http://securityreason.com/achievement_securityalert/54

In short, PHP's safe mode feature is a protection mechanism.  It is
can limit which OS resources can be accessed by a PHP application,
such as files or potentially dangerous functions.  The PHP interpreter
uses an incorrect order of behaviors related to canonicalization,
causing its safe mode check to be insufficient.  This could allow an
attacker to conduct path traversal attacks against applications.

Here, Security Reason mapped to CWE-264, which is a Category for
"Permissions, Privileges, and Access Controls."  They presumably did
this mapping because of the emphasis on bypassing safe mode - or,
because it's in the NVD Slice, which Bob Martin and I have been
advocating as a reasonable mapping system.  At any rate, the "safe
mode" functionality is the LOCATION of the issue - a protection
mechanism intended to provide access control.  It is not really
talking about WHAT the issue actually is.

Many people probably would have mapped this same issue to CWE-22 for
path traversal, which is the ultimate consequence.  (For those who are
interested in chains, notice how path traversal is the end link in
this case.)

Alternately, you could map to the more generic "protection mechanism
failure" (CWE-693), a new entry, which might be regarded as a
"property of the consequence," or alternately, an intermediate link in
a chain.

Then there's another weakness that people often call the "root cause."
It appears that some inputs are checked against safe mode, but then
those inputs are later canonicalized in a way that generates a result
that bypasses safe mode.  This is CWE-180, "Incorrect Behavior Order:
Validate Before Canonicalize."  This entry's perspective is largely
based on "code properties" - i.e., it basically involves properties of
code that are effectively independent of the types of security
problems they introduce (Consider CWE-227, API Abuse, as another
example of an entry focused on code properties.  The implications of
the API abuse will vary widely depending on the functionality and
assumptions of the API).

So, we have at least 4 potential CWEs that this issue could be mapped
to, because each CWE is written from different perspectives, or
applies to different parts of the chain.  This should have obvious
implications for understanding tool capabilities.  If one tool maps to
CWE-x, and another tool maps to CWE-y, then it will appear like two
unrelated problems are being covered, when they might just be
different pieces of the same problem.

The question becomes, which mapping should tool vendors or researchers
use, and in which context?  Ideally, we would like mapping to be
repeatable, i.e. independent of who's doing the mapping.

Should CWE get rid of CWE-264 entirely, since it's a category?
Absolutely not!  It's a very useful way to group things in a way that
reflects how humans think, and essential for some views.  And in the
CVE/NVD world where you don't have much information, and you only want
a couple dozen CWE's to map to, it serves its purpose well.  But,
neither does CWE-264 belong in the natural hierarchy, because it's not
about a specific type of weakness.  So, we're moving it out of the
natural hierarchy (along with other categories), into a new view that
we're informally referring to as a "programming concepts" view.

What about defining guidelines that would map to CWE-22 (path
traversal)?  This is probably how most people would map these days.
One could argue that CWE-22 should only be applied in cases where
there's a failure to even TRY to prevent '..' and related sequences.
In this specific case though, in my personal opinion, the most
appropriate mapping is CWE-180, the root cause.

So - even if we establish mapping guidelines that say "stay away from
categories," a mapper would still be looking at a couple different
weaknesses.  If we suggest: "stay away from categories AND
consequences," then the mapper would (hopefully) arrive at CWE-180 as
well.  This assumes that the person doing the mapping is following
these guidelines, however - which in practice doesn't always happen.

Suggesting that a mapper should "find the root cause" might be more
useful, but that would require a certain mindset that not all mappers
are familiar with, especially if they conduct application
vulnerability research.  In addition, tools aren't necessarily focused
on root causes.  If we go in this direction, then we might want to
actively discourage mapping to weaknesses that are solely (or
primarily) about consequences, such as NULL pointer dereferences.

Then there's another possible guideline - "map to everything that
matches."  This has certain strengths and limitations.  It would
effectively support audiences with multiple perspectives, so it would
be useful for people to understand the general contents of a single
tool or repository.  But it probably wouldn't work well for a deep
analysis of multiple tools.

The issues I've discussed are illustrative; I don't expect us to come
up with any quick and easy answers.

But, now that we're more specifically aware that we have these perspective
challenges, we are working on identifying and labeling the different
perspectives that are currently being used in CWE.  We are currently
examining various tool repositories to provide real-world examples for us
to work with.  This effort won't be complete for the release of CWE 1.0,
but I'd like to be able to describe the problem in an understandable way.

Any suggestions or concerns are more than welcome, whether to this list or
to cwe@....

- Steve

[McGovern, James F (HTSC, IT)]

 As soon as the next version of CWE is released, is there an equivalent
plan to communicate this to Gartner, Forrester and The Burton Group?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

[Robert A. Martin]

Hi James,

That would be something we would be interested in doing but probably
through direct discussion with specific interested individuals at
each organization.

Anyone with suggestions on who to work with at these or other such
groups or on ideas about how to educate them about CWE please feel
free to contact me directly or through this list.

We know some of the appropriate people but would welcome suggestions and ideas.

Bob Martin
CWE Project Leader


At 11:57 AM -0400 7/9/08, McGovern, James F (HTSC, IT) wrote:

>  As soon as the next version of CWE is released, is there an equivalent
>plan to communicate this to Gartner, Forrester and The Burton Group?
>
>
>*************************************************************************
>This communication, including attachments, is
>for the exclusive use of addressee and may contain proprietary,
>confidential and/or privileged information.  If you are not the intended
>recipient, any use, copying, disclosure, dissemination or distribution is
>strictly prohibited.  If you are not the intended recipient, please notify
>the sender immediately by return e-mail, delete this communication and
>destroy all copies.
>*************************************************************************

[McGovern, James F (HTSC, IT)]

 You typically start this process by filling out the briefing requests
on each analyst site:

http://www.forrester.com/Briefing/Process
http://www.burtongroup.com/Contact/VendorBriefing.aspx
http://www.gartner.com/it/about/vbriefings_faq.jsp

-----Original Message-----
From: Robert A. Martin [mailto:ramartin@...]
Sent: Wednesday, July 09, 2008 12:24 PM
To: McGovern, James F (HTSC, IT); cwe-research-list@...
Subject: Re: Industry Analyst Coverage of CWE

Hi James,

That would be something we would be interested in doing but probably
through direct discussion with specific interested individuals at each
organization.

Anyone with suggestions on who to work with at these or other such
groups or on ideas about how to educate them about CWE please feel free
to contact me directly or through this list.

We know some of the appropriate people but would welcome suggestions and
ideas.

Bob Martin
CWE Project Leader


At 11:57 AM -0400 7/9/08, McGovern, James F (HTSC, IT) wrote:
>  As soon as the next version of CWE is released, is there an
>equivalent plan to communicate this to Gartner, Forrester and The
Burton Group?

>
>
>***********************************************************************
>** This communication, including attachments, is for the exclusive use
>of addressee and may contain proprietary, confidential and/or
>privileged information.  If you are not the intended recipient, any
>use, copying, disclosure, dissemination or distribution is strictly
>prohibited.  If you are not the intended recipient, please notify the
>sender immediately by return e-mail, delete this communication and
>destroy all copies.
>***********************************************************************
>**

*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************