bugtraq - Re: [HV-HIGH] Microsoft Jet DB engine vulnerabilities

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 for Android: free password hash cracker in your pocket

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

Date: Sun, 3 Apr 2005 14:12:59 -0700
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: "Denis Jedig" <seclists@...eticon.de>,
	"bugtraq-securityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: [HV-HIGH] Microsoft Jet DB engine vulnerabilities

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