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