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