|
BugTraq
[HV-HIGH] Microsoft Jet DB engine vulnerabilities Mar 31 2005 09:53PM vuln hexview com (1 replies) Re: [HV-HIGH] Microsoft Jet DB engine vulnerabilities Apr 01 2005 12:53AM Thor (Hammer of God) (thor hammerofgod com) (1 replies) Re: [HV-HIGH] Microsoft Jet DB engine vulnerabilities Apr 02 2005 08:59AM Denis Jedig (seclists syneticon de) (2 replies) Re: [HV-HIGH] Microsoft Jet DB engine vulnerabilities Apr 03 2005 05:13PM Steve Shockley (steve shockley shockley net) (1 replies) Re: [HV-HIGH] Microsoft Jet DB engine vulnerabilities Apr 04 2005 06:23PM Son SonOfLilit (sonoflilit gmail com) |
|
Privacy Statement |
> 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
[ reply ]