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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Fri, 20 Feb 2004 01:39:44 -0500
From: Stuart Moore <smoore.bugtraq@...urityglobal.net>
To: thor@...x.com, bugtraq@...urityfocus.com
Subject: 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