is predicatable file location a vuln? (was RE: Aol Instant Messenger/Microsoft

[Stuart Moore]

Thor,

Hi. Good summary of the previous posts regarding the 'shell:' issue.


> Being able to store arbitrary content in a predictable file location is
> a vulnerability category of its own

An interesting category, for sure. I think this point deserves discussion. Is the use of
predictable file locations really a vulnerability? We know that it can certainly
facilitate exploits, but is it a vulnerability in and of itself? (Or is it even an
"exposure" as CVE defines?)

One measure that can be used to determine whether a bug (or a feature!) represents a
vulnerability is if the result creates a security impact (e.g., dos,
modification/disclosure of info, user access, arbitrary code execution, etc...).

Using that measure, some (hopefully) clear examples of non-vulnerabilities: How about
/var/spool/mqueue? Very predictable location (and you can inject content into files in
this directory). But, probably not a vulnerability. What about FTP servers? Probably
not a vulnerability.

But this could get messy. What happens when two issues *must* be combined inorder for a
security impact to occur?

My personal opinion differs from yours (and from SecurityFocus's) regarding BID 8900
(Flash) and the nullsoft and icq BID issues. I think they are not vulnerabilities, but
instead are a few of many, many leverage points for porous MS IE/OS security boundaries.
But maybe you could make an argument that some popular Win apps make little or no use of
OS security features and so are at fault. Or maybe you could say that an application
written for an OS that is known to have security boundary issues is negligent in using
predictable locations. Uh oh, I guess I could really start chasing my tail here ...

Perhaps a good question for the Secure Coding list (secure-coding.org)?

Stuart

[Steven M. Christey]

Stuart Moore said:

>An interesting category, for sure. I think this point deserves
>discussion. Is the use of predictable file locations really a
>vulnerability? We know that it can certainly facilitate exploits, but
>is it a vulnerability in and of itself? (Or is it even an "exposure"
>as CVE defines?)

The CVE definition of "exposure" generally involves issues that can be
building blocks or stepping stones for the exploitation of other
issues. Our classic example is running the finger daemon, which
allows someone to guess valid usernames on the server. In general,
knowing these usernames is not in and of itself a major problem, but
it can be an important component of the exploitation of a more serious
issue. A bug that leaks the absolute pathname for a web server isn't
necessarily a huge risk itself, except it greatly simplifies (or even
enables) the exploitation of directory traversal vulnerabilities.
These types of problems are generally included in CVE.

Note: the "exposure" term has been used in other ways in the security
community (e.g. the "Windows of Exposure" concept), so we don't try to
push our own definition in any real fashion.

>I think they are not vulnerabilities, but instead are a few of many,
>many leverage points for porous MS IE/OS security boundaries. But
>maybe you could make an argument that some popular Win apps make
>little or no use of OS security features and so are at fault. Or
>maybe you could say that an application written for an OS that is
>known to have security boundary issues is negligent in using
>predictable locations. Uh oh, I guess I could really start chasing my
>tail here ...

As the editor for CVE, I've generally taken your last position. You
often have a "design choice" and a number of "implementation errors"
that do not account for security-critical aspects of that design
choice (in fact it's an unproven theory of mine that many
implementation errors are directly facilitated by design choices).

- if a design choice enables certain classes of implementation
errors, then it might be regarded as a "design flaw." People may
disagree as to whether it's a vulnerability or an "exposure."
Consider the design choice of including strcpy() in standard C
libraries: strcpy(), IF PROPERLY USED, is secure; but as we all
know, it's quite prone to misuse that leads to overflows (and we
could extend this to general design choices in C itself).

- any piece of software that does not work around this design flaw,
itself has an "implementation error" that poses a vulnerability or
exposure. In the strcpy() case, we have many developers who don't
work within the constraints of the design flaw (i.e. "don't give
strcpy() a source that's bigger than the destination"), leading to
an implementation error. For PHP, we have a design choice that
facilitates "remote file inclusion" vulnerabilities in a variety
of PHP applications.

CVE identifiers are frequently assigned for implementation errors, and
sometimes for design flaws. Note that many "application vendors" will
fix the implementation bugs that are facilitated by the design
flaw/choice (consider MS-DOS device names, for example).

In this case, I think that the reliance on unpredictable file
locations for enforcing security boundaries is a design choice that
has a growing number of implementation vulnerabilities when the file
location becomes predictable. Just like there isn't a CVE name for
"strcpy is in the standard C libraries," there isn't a name for
"dependency on unpredictable file location," nor is there a name for
"PHP has a remote file inclusion feature."

>What happens when two issues *must* be combined inorder for a
>security impact to occur?

For CVE, we treat it like this:

- if each issue is a security risk ON ITS OWN, then we try to assign
separate identifiers (the general question we ask is: "if you fix
issue A, then does issue B still pose a problem? And vice
versa?")

- if the problem is an INTERACTION between 2 issues, but the
interaction MUST be present to be security-related, then the bug
is in the interaction itself, so we assign a single identifier and
try to write the CVE description in a way that emphasizes the
interaction.



Steve Christey
CVE Editor