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  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




Powered by blists - more mailing lists