----- Original Message -----
From: "Ansgar Wiechers" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 03, 2003 1:11 AM
Subject: Re: Ten least secure programs
> 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.
The point is, it's insecure. It's not meant only for use on a LAN with
trusted senders. The point is, it's exploitable by allowing things to
happen that it should not, even for what you state it's purpose is. Agreed
that it's not just Outlook that's the problem in this scenario, but that
program itself has these flaws that do exist, so the program itself is the
problem at hand, even if it is partly what it's tied into.
> > > > 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,
Right, how it's accessed, the protocol, isn't the point. This is what I
meant.
> as ist would apply to telnet as well, and
> neither tunnels nor sftp come out of the box when you install an ftpd.
Right, just like programs don't come configured, but lack of configuration
doesn't make them insecure programs. They would be an insecure program to
use, but the program serves it's pupose in the limits it's supposed to have
and can't be exploited to gain any state of compromise, so it's secure.
Obviously there are FTP and telnet programs that are insecure, but the way
it's accessed, built before things like sftp, scp, etc. existed or became
popular, doesn't equate to that program itself being insecure--it's just
using it that's a security issue... just as having bash listen on a high
port for connections, running as root would be insecure--but that alone
doesn't make the bash shell an insecure program. This is why I questioned
if this is about programs, protocols, how it's used or accessed.
> And why would you want your users to use FTP clients when scp (or sftp)
> could be used instead?
I don't know, I can't think of a reason.
--
Regards,
Tim Greer [EMAIL PROTECTED]
Server administration, security, programming, consulting.
---------------------------------------------------------------------------
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
----------------------------------------------------------------------------
