How to check whether a .mdb file contains executable content?

[Guest]

With "startup" feature and no VB security setting, opening a .mdb file is as
dangerous as that for .bat file. How can I check a .mdb file before opening
it?

I have done some checking and find that all my .mdb file with VBA code
contains "VBE6.DLL" when I open the file with notepad. "VBE6.DLL" cannot be
found in files containing data only. Can I conclude that all Access
Application with VBA code contains "VBE6.DLL"? Is there other way to check?

 

[TC]

The method that you describe, might or might not be ok, depending on
whether you need it to be 100% accurate, or whether you can accept
false positives and/or negatives.

MDB files contain large amounts of uninitialized space. These are
filled (in the file) with whatever data was in memory when the file was
created. When you find a plain text match, eg. for VBE6.DLL, it's
impossible to tell whether that data is actually /used/ in that file,
or whether those characters are there "by chance", in one of the
unitialized parts.

So even if files /with/ code, /always/ contain VBE6.DLL, it's quite
possible that files /without/ code, also contain that string. So your
check would probably return some false positives: it says there /is/
code, when really there isn't.

Maybe you could have a trusted MDB, which used methods & properties of
the Access object model to open the other database (without running any
code), and looked for the existance of standard modules & class
modules?

Maybe you could start a copy of Access with the macro security level
set to High for that specific run of Access. Then try to open the
database. It it /opens/, you can conclude that it has no code, or the
code is signed. If it doesn't open, you conclude that it does have code
& the code isn't signed. Then you could use win32 API tricks to close
it (if it did open). From VBScript:

dim oAccess, db
set oAccess = createobject (":access.application")
oAccess.AutomationSecurity = 2 ' High.
set db = oAccess.opendatabase ("...")
(etc.)

The only other way that I can think of, is to parse the file content at
the binary level, and look inside the relevant data structures. You
won't find much (if any) public information on this. I imagine that the
antivirus vendors have licenced such code, from the people who have it,
so their products can get at the code within an MDB.

HTH,
TC [MVP Access]

 

[TC]

Then you could use win32 API tricks to close it (if it did open)

Hmm, no need for tricks: just close it through the db reference.

HTH,
TC [MVP Access]

 

[Guest]

Maybe you could start a copy of Access with the macro security level

set to High for that specific run of Access.

Thank you for your reply. I am using MS Access 2000. I cannot find where I
can set the macro security level to be high.

The method that you describe, might or might not be ok, depending on
whether you need it to be 100% accurate, or whether you can accept
false positives and/or negatives.

MDB files contain large amounts of uninitialized space. These are
filled (in the file) with whatever data was in memory when the file was
created. When you find a plain text match, eg. for VBE6.DLL, it's
impossible to tell whether that data is actually /used/ in that file,
or whether those characters are there "by chance", in one of the
unitialized parts.

So even if files /with/ code, /always/ contain VBE6.DLL, it's quite
possible that files /without/ code, also contain that string. So your
check would probably return some false positives: it says there /is/
code, when really there isn't.

Maybe you could have a trusted MDB, which used methods & properties of
the Access object model to open the other database (without running any
code), and looked for the existance of standard modules & class
modules?

Maybe you could start a copy of Access with the macro security level
set to High for that specific run of Access. Then try to open the
database. It it /opens/, you can conclude that it has no code, or the
code is signed. If it doesn't open, you conclude that it does have code
& the code isn't signed. Then you could use win32 API tricks to close
it (if it did open). From VBScript:

dim oAccess, db
set oAccess = createobject (":access.application")
oAccess.AutomationSecurity = 2 ' High.
set db = oAccess.opendatabase ("...")
(etc.)

The only other way that I can think of, is to parse the file content at
the binary level, and look inside the relevant data structures. You
won't find much (if any) public information on this. I imagine that the
antivirus vendors have licenced such code, from the people who have it,
so their products can get at the code within an MDB.

HTH,
TC [MVP Access]

 

[TC]

I meant to set the macro secuity level through code, for one run of
Access (not for the whole PC), by using the AutomationSecurity
property. I did not mean for you to change it through the normal UI,
for the whole PC. But this is irrelevant to Access 2000, so you should
ignore that part of my reply.

HTH,
TC [MVP Access]

 

[david epsom dot com dot au]

An autoexec macro is run automatically if it is present.

You can use ADO or DAO to check for the presence of
an autoexec macro: if it is present, it will be listed
in MSYSobjects.

The other thing to check is the startup form property.
Using a dao database object:

db.Containers("databases").Documents("msysdb").Properties(StartUpForm)

The StartUpForm property does not exist if no start up form is set.

To do these checks, you need open the database with DAO.

Using DAO to open the database is not the same as using Access,
it won't run any code at all.

(david)

 

[jacksonmacd]

Open the file while holding the shift key to disable any startup code.
Presumably you are not opening unsolicited MDB files from unknown
sources.

With "startup" feature and no VB security setting, opening a .mdb file is as
dangerous as that for .bat file. How can I check a .mdb file before opening
it?

I have done some checking and find that all my .mdb file with VBA code
contains "VBE6.DLL" when I open the file with notepad. "VBE6.DLL" cannot be
found in files containing data only. Can I conclude that all Access
Application with VBA code contains "VBE6.DLL"? Is there other way to check?

**********************
(e-mail address removed)
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security

 

[Guest]

Hi.

This begs the question: What, pray tell, are you going to do with the
executable content if you actually find any?

Are you going to import the tables into a new database, leaving this
potentially malicious executable content in the original MDB file (presumably
for subsequent deletion)? If so, then why bother figuring out how to check
for executable content first, instead of just importing the tables into a new
file, deleting the original, and be done with it?

Are you going to delete this executable content? Executable content, by the
way, includes VBA code, action queries and macros, so you may have to get rid
of more than just modules if you're chucking executables. If you delete this
executable content, will this cripple the database application? If so, how
much will it cost you to fix it and how much time is it going to take a
developer you know is trustworthy to replace the deleted code, queries and
macros?

Are you going to delete the entire MDB file, since, as you say, it's
potentially dangerous? If so, how much will it cost you and how much time is
it going to take a developer you know is trustworthy to replace it?

What has your risk assessment revealed that you are fearful of executable
content within MDB files? Are you expecting to find a virus? Has a former
disgruntled employee or a dysfunctional relative warned of impending MDB code
bombs? MDB query bombs? MDB macro bombs? Are you expecting an unknown
assailant to E-mail you any of the above?

If it's a virus you suspect, then scan the files with a commercial antivirus
software application, such as Norton or McAfee, before opening them. If it's
a former disgruntled employee's or dysfunctional relative's maliciousness you
suspect, then make sure you have backups of your computer systems and
important files, and then take legal action if his maliciousness actually
hits your computers, because tampering with people's computers where harm
results is a criminal act. If it's an unknown assailant sending you
malicious files, then you could check to determine whether the shift bypass
has been disabled (if so, then re-enable it) before opening the file by
pressing the <SHIFT> key until the database is completely opened, then
examine the executable content for anything malicious. But if you're afraid
of what unknown sources are sending you, then why would you even bother
opening the file? Open MDB files only from developers you trust, and
there're no worries if you have -- and use -- antivirus software.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
See http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.