is predicatable file location a vuln? (was RE: Aol Instant Messenger/Microsoft Internet Explorer remote code execution)
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