Bugtraq: is predicatable file location a vuln? (was RE: Aol Instant Messenger/Microsoft Internet Explorer remote code execution)

[Stuart Moore <smoore.bugtraq () securityglobal net>]

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