Patr Traversal and some challenges for CWE

I'm changing the subject line because Robert's question touches on some
systemic CWE issues, and we'd really like the CWE community to give us
their thoughts.


Robert C. Seacord asked:

> I have not been able to use "..." in place of "..\.." on any of my
> windows systems.  Where is this an issue?

I believe this applied to older Windows systems, at least NT.  I
distinctly remember testing it, because I couldn't believe it was true :)

> As a more general comment--have you given any thought to collapsing some
> of these together?  There seem to be an awful lot of nuanced
> distinctions.  For example, if you were to introduce the term "separator
> character" which could be equal to '\' or '/' you could quickly
> eliminate a number of leafs in this section.

We've done a little bit of thinking on this.  The path traversal nodes are
one part of the tree that seems excessively deep.

Note that the current path traversal leaves, such as "..." and "....//",
are all attack-focused.  They concentrate on specific manipulations that
are nonetheless a little different from each other.

There are a few different ways this could be handled.

One would be to abstract the leaf nodes like so:

  - merge of '/' or '\' as "directory separators".  Issue: this doesn't
    account for the frequent occurrence where an application accounts for
    one separator but not the other, especially in Windows systems where
    both "/" and "\" often work.

  - merge of leading/trailing/internal separators.  Issue: as with / and
    \, sometimes you'll encounter where one works but not the other

  - merge multiple dots or other doubled sequences.  Issue: well, you get
    the drift.


A second approach is to focus more on the underlying weaknesses, and try
to infer WHY these manipulations really work.

In that sense, we might have something like:

  - the canonical example - "../"

  - failure to account for syntactic equivalence.  This might address
    multiple internal "//" and perhaps "..."

  - failure to account for OS-specific variants.  In relative path
    traversal, this might be "/" and "\" (Unix vs. Windows), as well as
    "..." and "C:\drive\letter" (Windows only)

  - protection mechanism failure (PMF): an attempt to protect against
    traversal is incorrect or incomplete.  Ideally, each PMF would have
    its own CWE as well.  But PMFs get into the whole complicated notion
    of weakness chains (a la integer-overflow-leads-to-buffer-overflow),
    and I'm not sure how we could best handle chains within CWE.
    However, it's a good topic to explore.

    At any rate, for example, "....//" might fall under this category,
    since it's not valid to the OS as-is, but a collapse-into-unsafe-value
    error (CWE-182) might reduce this string into "../" which then enables
    the traversal to take place.

As you can see, there are a few options.  The second approach, while more
weakness-focused, still has overlapping categories.

===== So what should happen to the current low-level leaf nodes? =====

If it's decided that these are too low-level, or the wrong perspective,
then some options for handling them are covered at
http://cwe.mitre.org/community/research/restructuring.html

But the question still remains about what to do.

Some CWE consumers might advocate that the existing low-level nodes should
stay as they are, because there are some cases where this precision would
be useful, such as in a pen-test or black-box scanning situation where you
would want to ensure broad coverage, *or* if a programmer is implementing
a protection mechanism and wants to figure out what potential problems
could arise.  However, these nodes, as currently described, are inherently
attack-focused.  In addition, you wind up with a risk of combinatorial
explosion if you try to ensure that CWE's coverage is complete in this
area.  Path traversal has been a favorite vulnerability of mine for years,
so I've studied it pretty closely, and I suspect that even the existing
set of leaf nodes is incomplete.

Others would think that a middle ground might be more appropriate.  This
makes sense for a few use-cases, including general education, as well as
characterizing code analysis tool capabilities - they mostly only spot
"pathname can be manipulated", so all (or most) leaf nodes would apply.

Note that CWE contains a LOT of nodes that are like this.  XSS (CWE-79),
Buffer Errors (CWE-119), and Information Leaks (CWE-200) are some other
examples.

===== The larger questions =====

The path traversal nodes illustrate some larger questions that we face for
CWE:

1) When there are competing perspectives, which ones do we adopt?  The
   use-cases we defined at
   http://cwe.mitre.org/community/research/stakeholders.html, plus
   feedback from the CWE research community (i.e. you), will help us to
   decide this.

2) If we adopt multiple perspectives, then how do we modify CWE so that it
   supports these perspectives, both internally within the XML, and
   externally in terms of presenting them to CWE consumers without
   confusing them?  Hopefully, views will be able to account for these,
   but there's also the question of resources/labor and where we direct
   our efforts (although community involvement might help here, too).

3) Do we aim for theoretical completeness at a low level for CWE, which
   could translate into combinatorial explosions and perhaps tens of
   thousands of CWEs, or do we live with incomplete nodes and the
   associated biases that they would indirectly introduce into
   quantitative comparisons?  Are there ways of handling the combinatorics
   without producing an excessively large set of CWEs?  (Some other MITRE
   initiatives such as CCE have their own ways of dealing with
   combinatorics.)


You can see some of these questions "in action" on the discussion points
page on the CWE web site, at
http://cwe.mitre.org/community/research/content_discussion.html

- Steve