Question for aaron about access security

[Wayne-I-M]

This is a copy from the post below - This "could" be against the forum rules
but I think it's too important not to have it's own thread so sorry if I
offend anyone.

But if there is a security risk with sending e mails from access it should
be searchable in it's own thread.

Please can you give a "specific" reason (or reasons) and do you know of any
fixes that I could use to make the (in my case SendObject) more secure. I
also use server side scripting from asp pages but I don't "think" thats a
risk ?? Unless you now different




***********************

SQL Server can send emails via XP_SENDMAIL

trying to do the same thing, on the client-- that is not reccomended
because it is a security risk

What security risk.

Sorry but I'm not an access "expert", I just make databases the best I can
and try to keep smileing.

I can't see how sending an e mail to someone is a security risk (other than
the normal attachments risk)

I have sent about a zillion people e mails over the last few years direct
from
access - so please explain security risk - really would like to know if I'm
doing something wrong.

 

[Wayne-I-M]

Bit dispointed aaron.
If you make claims then you could least give some specific backup reasons.
Just to say there is a security risk and not give additiona information is
not very good. There are many expert on this forum but i am not one of them.
Like I said I just write databases. So if someone says that what am doing
could be a security risk then I take that seriously (I am responsible for all
the IT in my company).

You should not make idle claims without anything add to it else.
There is a good saying in Italian that would describe this - but there are
enough people here who would understadn it that I would get in troble. Lets
just say it a not very nice to do thing.

I will not answer any more of your posts - and as I am one of the few people
here who does that it a lost to you.

 

[Arvin Meyer [MVP]]

Wayne,

There is no elevated security risk in sending email from Access, any more
than there is from Excel, or Outlook. The only email security risks worth
mentioning are from viruses using email from your address book. If that
address book is, in fact, an Access table, there is no security risk at all.

You should realize by now that those rantings have no basis in reality.

 

[Guest]

SQL Server and the Slammer worm brought the internet to its knees
in January 2003 with 20% packet loss at the peak, and 5 of the
13 root nameservers unaccessable. Following that experience, MS
turned off email and JET integration by default in SQL Server, and
made it email integration greatly more difficult in Access.

Using a computer connected to the internet is a security risk.
Sending email from a computer is a security risk.

Normal workstations are setup to allow users to send email,
which is risky, and the network infrastructure is set up to handle
this risk.

Sending email from a client is normally less risky in a business
environment than sending email from a server, because there
are a series of walls between the client and the internet which
are particularly designed to handle that risk: there have been
many client-based email worms, but none have caused the
problem that Slammer and SQL Server caused.

Using Access to send email does not add to the security risk
of a normal workstation.

Using SQL Server to send email does add to the risk of a normal
SQL Server installation.

Using Access to send email is less risky than using SQL Server
to send email. However, it is unlikely that this would be a reason
to use a client-based solution in an application where a server-based
solution was already in use.

(david)

 

[Tony Toews [MVP]]

SQL Server and the Slammer worm brought the internet to its knees
in January 2003 with 20% packet loss at the peak, and 5 of the
13 root nameservers unaccessable. Following that experience, MS
turned off email and JET integration by default in SQL Server,

I won't argue that point as I don't know enough about SQL Server.

and
made it email integration greatly more difficult in Access.

Now this puzzles me. Yes, MS made it more difficult to send emails via
automation in Outlook Express and Outlook. But that had nothing to do
with Access.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Guest]

Now this puzzles me. Yes, MS made it more difficult to send emails

automation in Outlook Express and Outlook. But that had nothing to
with Access.

Yes, that is what I meant.

But 'nothing to do with Access' ? Office integration is the standard
way to do things in Access :~). 'Greatly' you could quibble about...

(david)

 

[David W. Fenton]

I won't argue that point as I don't know enough about SQL Server.

The timeline makes absolutely not sense in terms of releases of SQL
Server and Jet that followed Slammer.

Now this puzzles me. Yes, MS made it more difficult to send emails
via automation in Outlook Express and Outlook. But that had
nothing to do with Access.

And it wasn't triggered by Slammer, which had zilch to do with email
-- Slammer was entirely the fault of the sa account being configured
by default with no password.

 

[Arvin Meyer [MVP]]

And it wasn't triggered by Slammer, which had zilch to do with email
-- Slammer was entirely the fault of the sa account being configured
by default with no password.

Correct. I spent an entire weekend at multiple client sites fighting
Slammer. Slammer usurped port 1433 (the SQL-Server port) and we went into
action shutting down that port at every router. In the end. none of our
clients got Slammer, but we got it on 1 of our webservers and an instance of
SQL-Server running an early Sharepoint site. The webserver was only offline
for an hour and a half. The Sharepoint site, being a test site, was simply
removed.

 

[Guest]

-- Slammer was entirely the fault of the sa account being

configured by default with no password.

Slammer was the result of an already-patched buffer over-run bug
in SQL Server. Because the patch had already been applied by
most production sites, most of the packet storm was caused by
unused development machines and MSDE installations.

The timeline makes absolutely not sense in terms of releases of
SQL Server and Jet that followed Slammer.

When was SP7 released? Maybe all the work was already in
train because of Code Red (IIS)?

(david)

 

[Tony Toews [MVP]]

Slammer was the result of an already-patched buffer over-run bug
in SQL Server. Because the patch had already been applied by
most production sites, most of the packet storm was caused by
unused development machines and MSDE installations.

Ah, ok. I had missed those details back then.

However I also put a substantial amount of blame at Microsoft.
Patching SQL Server back then was a huge PITA. Unzip this file,
rename those files, copy the file replacements in the folder. MS
needed to simplify that procedure greatly. And to their credit they
did so.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

Slammer was the result of an already-patched buffer over-run bug
in SQL Server. Because the patch had already been applied by
most production sites, most of the packet storm was caused by
unused development machines and MSDE installations.

That was the vulnerability it exploited, but it was able to connect
via open ports (i.e., no password on sa).

And it had NOTHING to do with email, as you had earlier implicitly
alleged.

When was SP7 released? Maybe all the work was already in
train because of Code Red (IIS)?

Why would an IIS vulnerability cause MS to rework SQL Server?

You're the one making the allegation here. *You* are the one who
needs to provide the documentation backing up your assertion -- it's
not my job to disprove your assertions, but your job to demonstrate
taht they are correct.

 

[David W. Fenton]

However I also put a substantial amount of blame at Microsoft.
Patching SQL Server back then was a huge PITA. Unzip this file,
rename those files, copy the file replacements in the folder.
MS needed to simplify that procedure greatly. And to their credit
they did so.

It is certainly a pain for SQL Server 2000. I re-installed it last
summer on a client's rebuilt server and despite downloading all the
patches, and thinking I'd run them, ended up with an unpatched
installation that ran for 3 months before I realized that it was
unpatched (because I ran into a bug that the Knowledge Base
identified as having been patched; when I checked the version, I
found out the patch hadn't been installed, despite my having
definitely run the patch executable).