Taxonomies and multi-factor vulnerabilities

["Steven M. Christey" <coley () mitre org>]

Frank O'Dwyer asked:

> Also what makes you think these things fit into a hierarchy at all,
> never mind an objective one? There are any number of ways to
> categorise these things. They have a habit of belonging in more than
> one category, too.

One of the main problems is that many vulnerabilities are combinations
or compositions of multiple factors, each of which can be a
security-relevant problem on its own, and a hierarchy can't capture
that.

These Multi-Factor Vulnerabiities (MFVs) are difficult to classify
effectively, since currently available schemes treat vulnerabilities
as if they are atomic, and any MFV could occupy multiple places in a
hierarchy.

Consider the classic MFV, which is exploited by symlink following.
OK, so it's not the most common issue in web application security, but
it still serves as a demonstration.

Factors include:

    - permissions (attacker has access to a directory the victim
      operates in)

    - filename predictability (attacker knows, or can predict, what
      filename will be written to)

    - race condition

    - design factor: lack of standard, widespread, and/or portable
      support for safe temporary file creation in most programming
      languages, lack of atomic operations for effectively creating
      symlinks

This issue occupies several places in most classification schemes.

Remove any one of these factors and you've either eliminated the
vulnerability entirely, or you've reduced the attack surface.

Another multi-factor vulnerability occurs in directory traversal
problems.  Suppose you have a web application that runs on Windows
that tries to filter out bad "../" requests (yes there are much better
ways to protect against this issue, but let's face it, that's what a
lot of programmers with an ounce of clue do).

Now suppose an attacker uses "hex-encoded backslashed directory
traversal" sequences to break into the app using a sequence like
".%2e\.%2e\FILE.dat" and succeeds.

There are multiple factors involved:

 - programmer checked for ".." before canonicalization - OK so it's a
   canonicalization error

 - programmer didn't account for "\" being the underlying directory
   separator character in Windows - no wait, it's an incomplete
   blacklist

 - programmer generated a filename outside the web root - so the
   result is "directory traversal"

 - the design didn't do whitelisting

 - the design (or the implementation?) didn't use OS API routines to
   obtain the real full pathname


I haven't tried to determine how many publicly reported
vulnerabilities are multi-factor, but it wouldn't surprise me if it's
in the 10-20% range these days.  If you include design flaws as
factors, that number is probably a lot higher.

A lot of "buffer overflows" these days are multi-factor.

I know that a lot of people on this list understand this, but this is
one of the major challenges for building the "right" scheme to
effectively capture these kinds of problems.  I wish I knew the answer
but I'm only just starting to ask better questions.

- Steve