Make it possible to stop Access Desktop from being an Automation Server so that security is improved
Currently, if a user has Access running, much of what is meant to be secured can be accessed from another program, e.g. Excel, via Automation. This is not good.
Mark Burns commented
You are missing the concept.
You appear to understand only a part of the automation picture.
Someone: "User A"
starts a secured MS-Access application under their credentials on a PC, logs it in under their permissions and rights (including their access to the back-end data tables).
Someone else - in a variety of possible real-world scenarios - comes along and uses COM API calls to grab hold of the RUNNING instance of MS-Access in memory (think: a hostile vbscript virus/malware). This script then uses the MS-Access COM API calls to do whatever it is the creator/user("User B" here) want it to do. When it runs, it runs under the cover of "User A"'s login credentials and security rights.
This is entirely possible, and there is no real defense against it. There is no built-in/"standard" means of blocking or otherwise defeating the "hostile" code in this scenario, and it can do whatever damage to the back-end tables that the legitimate user has permissions to do.
This is the reason for this request.
'Whatever the App has permissions for and access to at any given time, can be exploited through the COM Automation security hole.' The App has the permissions and access that are granted to the logon. No more, no less.
This is VBScript:
PathToMDE = "c:\myfile.mdb"
Set MyConn = CreateObject("ADODB.Connection")
MyConn.Open "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TI_Data;Data Source=myserver\SQLEXPRESS"
'MyConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\myfile.mdb"
Set RS = MyConn.Execute("Select versionnumber from tblVersion;")
splitstring = rs.fields("VersionNumber")
LocalSplit = split(splitstring,".")
x = UBound(LocalSplit)
LocalSplit(x) = LocalSplit(x) +1
MyConn.Execute("UPDATE tblVersion SET tblVersion.VersionNumber = " & chr(39) & join(localsplit,".") & chr(39))
You don't need MS ACCESS to get after things, you need permissions as the logged on user.
If I have no rights to that table, or read-only rights, the VBScript fails. If I do have those rights, it works. But I am not using Access to update that version number, I am using VBScript. You can secure the front end through creating compiled apps. You can secure the backend through SQL Server, but at the end of the day if your logged on users are trying to hack your data using access granted them to do their jobs, you don't have an application problem, you have an HR problem.
Tom van Stiphout commented
I completely agree with Mark. Was just researching this today for a company with a commercial Access application in the EU, and there is a concern it will not for much longer be able to be allowed to be used due to possible exposure of PII. If we could avoid Access to be automated, that would add a lot to the security. I have more details if needed (but not for this public forum).
Alan Cossey commented
The order that posts get displayed here is a bit unfortunate. It looks at first sight as if Crystal, Bonnie Hicks and Nick67 are disagreeing with Mark Burns, but Mark posted *after* their posts. Mark's summary is a very good one.
Mark Burns commented
@Anders is exactly correct. This security hole is ripe for unlimited abuse. Get someone to start and log in to your application. I can then grab the handle via vbscript and read EVERYTHING your app can read from the FE and BE databases it uses - UNLESS you program the app VERY defensively - which is HIGHLY uncommon. @Nick67...even your SQL Server BE is completely vulnerable to this. Whatever the App has permissions for and access to at any given time, can be exploited through the COM Automation security hole. Worse, malicious code could damage as well as read your SQL database, assuming your app has those permissions.
I don't think this will ever happen, as it would break the current Automation model.
If you need the data secured, that's what SQL Server Express Edition is for.
If you need the file secured, that's what NTFS is for.
If you have a user who you can't trust to keep their fingers out of the pies they don't belong in, yes that's a problem.
This pales in comparison to the problem of the Nav Pain flying open, and exposing the tables, though.
Bonnie Hicks commented
Encrypt your front and back end separately to avoid this issue.
Anders Ebro (TheSmileyCoder) commented
I agree fully. The amount of abuse that can potentially be done through that loophole is unlimited.
@Crystal: I don't want to post a guide here on how to abuse it, but Crystal if you want more info, just mail me.
with all due respect, if the user has Access running already, then credentials have already been entered and it seems like a waste of time to enter them again ...