On 2003-07-02 Tim Greer wrote:
> 
> ----- Original Message -----
> From: "Ansgar Wiechers" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 01, 2003 1:52 AM
> Subject: Re: Ten least secure programs
> 
> > On 2003-06-28 Chris Berry wrote:
> > > 1) Microsoft Outlook
> >
> > I beg to differ on this one. Outlook is a groupware client and is
> > therefore *designed* to be insecure.
> 
> It's not designed to be insecure.  The difference is that it's
> accepting content it should not and processing that content in a
> manner it should not. It, like most MS products, do not comply to
> RFC's and that alone opens big holes.  That is not always the issue
> and it's not the only problem, but this is not built to run in an
> insecure manner as you suggest, as if people are using the wrong tool
> and it's their fault.  I can agree in some ways it's the wrong tool,
> but it's not supposed to be.

I apologize if I didn't make clear enough what I meant by saying
"designed to be insecure". I will try to be more precise this time.

Outlook is a groupware client and as such is (or at least should be)
designed to enhance productivity, not security. In a groupware
environment a user *should* be able to open documents from within the
message. Macros *should* be able to access the address book or other
components e.g. word processor or spreadsheet (so you can automate
tasks). You *should* be able to use HTML or something else for formating
in messages. You *should* be able to access global address books and
access the data of co-workers (e.g. to assign tasks to them or to plan
meetings).
None of the above apply to internet mail.

A groupware environment is much more trusted than the internet, so you
should check every single bit that goes into your groupware environment
and maybe every single bit that leaves it, but you should not check
every bit circling inside it.

And to repeat that again: virtually all security holes in Outlook (as
well as in Outlook Express) are holes in Internet Explorer, which is the
real culprit (at least IMO). No, I don't count layer 8 security breaches
here.

> > > 2) Telnet
> > > 3) Sendmail
> > > 4) IIS Server
> > > 5) Wireless networking
> > > 6) PHP
> > > 7) ?
> > > 8) ?
> > > 9) ?
> > > 10) ?
> >
> > You might want to add FTP in general and BIND (at least earlier than
> > version 9) here.
> 
> Are insecure programs and the protocols to connect to them now
> resulting in the program itself being insecure?  So, is I tunnel to an
> FTP server or use sftp on the same FTP service, that means the FTP
> service isn't a less secure program now?

Tunneling isn't the point, as ist would apply to telnet as well, and
neither tunnels nor sftp come out of the box when you install an ftpd.
And why would you want your users to use FTP clients when scp (or sftp)
could be used instead?

Regards
Ansgar Wiechers

---------------------------------------------------------------------------
Evaluating SSL VPNs' Consider NEOTERIS, chosen as leader by top analysts!
The Gartner Group just put Neoteris in the top of its Magic Quadrant,
while InStat has confirmed Neoteris as the leader in marketshare.
     
Find out why, and see how you can get plug-n-play secure remote access in
about an hour, with no client, server changes, or ongoing maintenance.
          
Visit us at: http://www.neoteris.com/promos/sf-6-9.htm
----------------------------------------------------------------------------

Reply via email to