Inline
Thor (Hammer of God) wrote:How is this a high-level vulnerability when a user must launch the file, simply resulting in possible code execution within that user's interactive credentials? If you're going to get them to launch a file, why not code up a nice juicy .exe for them and not bother with the other stuff?The user is opening a data file, like he would open a JPEG image or a MP3 audio file. Since the rule of thumb is that data does not harm, only code does, it is a security vulnerability.
I disagree... any data from an untrusted source, regardless of any perceived classification of "code" or not, must be considered potentially harmful; particularly in the case of "executable" files such as office documents. JPG's are parsed- MDB's are executed (per se). You've got to get a file on the system to begin with for this to be an issue... I would have to say that my "rules of thumb" are opposable to yours. ;)
Or even better, since it's an MDB file, code it up in an Access module- that way it won't even throw an exception.Newer Access versions throw a security warning if the VBA code is not signed and let the user disable VBA execution. The issue highlighted by hexview is able to circumvent this security-related feature.
You know, you make an excellent point. There are actually 2 code execution security mechanisms in Office2k3- one is running VBA in "sandbox" mode (blocking unsafe expressions) and the other is digitally signing the project/mdb to allow it to run at all. To be specific, VBA execution is not "disabled," as the entire project/mdb fails to load if the user does not accept the warning.
So yes, in an environment of trust, one could take advantage of a user's assumption that the file was valid to have them execute code-- however, one must also identify the fact that some other (greater) breach had to take place to get the file there in the first place. Given that, I still contend that this is not a "high" level issue, though I appreciate you bringing that point to bear as I did not think of that.
T