----- Original Message -----
From: "Vic Parat (NSS)" <[EMAIL PROTECTED]>
To: "Tim Greer" <[EMAIL PROTECTED]>; "Chris Berry"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, July 02, 2003 1:25 PM
Subject: Re: Ten least secure programs


> Phew!  What a mouthful!

Okay...

> I can tell where this is going but I seriously
> doubt it would have any educational aspects to it,

I don't think it's had that quality for a while.  If you can't deal with
your claims being responded to without taking it personally, I'm not sure
what to tell you.

> which is why we're all
> here.

I'd have thought so, but arguing about how some people lack skills for
configuring and installing programs somehow reflecting on a program itself
being insecure, really didn't help with that goal either.

> Anyways, since you are apparently the greatest programmer that has
> ever lived, I thank you for your enlightenments.

If you say so.  Apparently I'm an arrogant programmer because I don't agree
that every program out there _must_ be insecure to actually exist.  If you
can't manage to code a secure program, maybe you should take some courses.
Just sitting there and being content to blurt out these ridiculous and
untrue things, doesn't make them so.  The fact you claim it, ultimately just
means that logic alone dictates that you aren't qualified to make those
claims.

I'm serious, I'm not saying it to offend you and I'm not doing like you are
below, and just handing out sarcasm and insults, because I feel insecure
about not actually knowing about the subject matter.  But if you refuse to
believe that, you will likely never see the irony and the actual problem
being just that.  Think what you want, you're not the first to pretend to
know.  We have enough arm-chair experts, which accounts for all the problems
with programs and why we're having this debate now... and why it's even
turned into a debate.  Try and be more original.  I.e., put up, or shut up,
ego and empty claims don't impress me.

 > Just don't kick the dog when you get home;-)

Hey, good effort.  And, it's better than making a valid point anyway.

> Vic Parat, Sr. Security Architect
> Network Systems Security, LLC
> www.nssecurity.com

I don't buy it.  No security expert would be making such ludicrous
statements.  I didn't mean to hurt your feelings, but if you are going to
claim to run a security company, you should probably learn more about the
field and subject matter.
--
Regards,
Tim Greer  [EMAIL PROTECTED]
Server administration, security, programming, consulting.

>
> ----- Original Message -----
> From: "Tim Greer" <[EMAIL PROTECTED]>
> To: "Vic Parat (NSS)" <[EMAIL PROTECTED]>; "Chris Berry"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Wednesday, July 02, 2003 12:46 PM
> Subject: Re: Ten least secure programs
>
>
> >
> >
> > ----- Original Message -----
> > From: "Vic Parat (NSS)" <[EMAIL PROTECTED]>
> > To: "Tim Greer" <[EMAIL PROTECTED]>; "Chris Berry"
> > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > Sent: Wednesday, July 02, 2003 12:06 PM
> > Subject: Re: Ten least secure programs
> >
> >
> > > Not really interested in starting the "Apache vs. IIS" war but making
> the
> > > secured IIS vs. unsecured Apache comparison (no OS remember?) is not
"a
> > > weird argument to make", especially concerning this thread.
> >
> > I think is very much is.  After all, what does a default install have to
> do
> > with how secure the program is?  We're talking about the programs, not
the
> > quality of administration skills or configuration.  That is the essence
of
> > how secure a program is or not, not the lack of skills of the person
that
> > set it up.  If that was the case, this discussion is utterly a moot
point,
> > since everything is now 100% dangerous, unless it was a program that was
> > 100% secure and didn't _allow_ the user to mess with it.
> >
> > > I find it quite
> > > relevant in that the only true difference between a secure program and
> an
> > > insecure one is proper configuration /*my opinion*/.
> >
> > That is ridiculous.  That is the difference between a "secure
> configuration"
> > and a "non secure configuration".  Configurations may be limited by the
> > program, or be poor(er) by default, but that has no bearing on how
secure
> > the program itself is.  We are talking about programs, which are
insecure
> or
> > not, and by how much, not "what if this program wasn't configured".  Tat
> can
> > be true of anything and we can even discuss ways to make any service
> > insecure and this discussion is completely irrelevant.
> >
> > > Even with proper
> > > configuration, no program is void of bugs/vulnerabilities,
> >
> > That's not true at all.  It depends on the quality of code, who coded
it,
> > the design, what the code does, how it works and then configuration and
> how
> > it's run.  To say that no program is void of bugs and exploits is
> senseless.
> > Many programs have no history of bugs or exploits.  Sure, there's
usually
> a
> > bug somewhere in most programs, but not all of them.  Some bugs are
major
> > and some are very minute.  As for exploits, more programs lack exploits
> than
> > bugs.  A bug is one thing, but an exploit is another.  It's sickeningly
> > simple to secure a program, even if it does have a small bug
somewhere...
> if
> > there's even a bug at all.  The mentality to say that no program is void
> is
> > security issues is ludicrous!  And please don't sink to that "It's only
a
> > matter of time until someone finds one" as if it's simply not possible
to
> > have a secure program.
> >
> > > some just have
> > > not been discovered yet.
> >
> > Oh, there we go *deep friggin' sigh*... I knew that was coming.
> >
> > > Now what I do find to be a weird argument is the
> > > amount of configuration an OS (damn forgot about the no OS thing)
allows
> > one
> > > to do.
> >
> > Why?
> >
> > > Not trying to start the "Open Source vs. Closed Source" war either,
> > > but just because you can hack the kernel in Linux doesn't make it
> anymore
> > > secure.
> >
> > No, I didn't claim it did mean that.  But it means that you *can* secure
> it,
> > if it's not, because you have the *ability* to do so.  You can review
the
> > code and see potential or existing holes and fix this, you can modify it
> to
> > work in the most secure manner.  This is a fact, there's nothing to
debate
> > about it.  Sure, most people can't do this due to lack of skills, but
that
> > doesn't change the fact it matters.
> >
> > > That's left in the hands of the sys admin
> >
> > Or any home user that has the skills.
> >
> > > and yes you can do plenty
> > > to MS NT based OSs to make them just as secure as any Linux box.
> >
> > I'm not sure what is so confusing about this.  You can't just blurt out
a
> > statement and think that makes it so.  If you can't modify the source,
you
> > can not have the same amount of control.  You rely steadily on the
skills
> of
> > those whom developed and built the kernel.  You can't change it.  With a
> > Linux kernel, you rely on people too, but can fix, improve and modify it
> > (provided you have the skills).
> >
> > > And you
> > > can do plenty to make them insecure as well.
> >
> > Yes.
> >
> > > Now if this list is about "insecure programs, nothing more, nothing
> less"
> > > then why are items like telnet listed?
> >
> > I asked the same thing... Anyway, telnetd has had a history of some
> security
> > issues, if that helps.
> >
> > > Whose telnet, Sun's,Linux's,MS's?
> > > Telnet is a lot more then a program and so is nfs, rlogin, rsh, etc.
I
> > > think that this list does have some merit but it should definitely not
> be
> > > taken at face value.
> >
> > I agree, and we should be discussing the topic then--programs... not
> > configurations, not "if you keep it continually patched it's okay" and
not
> > protocols or misusing a program.  If the program can have it's
limitations
> > defeated to open a hole in a manner that would result in any type of
> > compromise, then it's insecure to some degree, depending on what that
is.
> > Hence, being listed.  Hence; MS IE, Outlook, IIS, BIND, Sendmail, PHP,
> > Apache, Exim, you name it... not some though (take note)l such as
TinyDNS,
> > Qmail, Perl, etc.  Now, my previous comment that all programs aren't
going
> > to be exploitable is true.  However, do not construe that to mean that
I'm
> > claiming there's no exploit waiting to be found in the (as far as we
know
> > right now) secure programs I just listed.  I know programs I code are
> secure
> > and it's due to how they are coded and built.  I'm not being arrogant,
> it's
> > simply a matter of only allowing specific things to happen or be done,
and
> > checking.  So, I can only say this about my own programs for certain...
> > though I admit it's possible I could have opened a hole and never knew
or
> > saw it--but I seriously doubt it given how I code and compile programs
and
> > how they will run.  In other words, the simple matter of the fact is,
most
> > of the programs mentioned that *are* insecure (or have a history of
being
> > insecure) were a direct result of simply having common sense checking in
> the
> > programs... really.
> >
> > > But anyways I can feel Chris Berry thinking this is not what he is
> > > interested in so then I will go ahead and post my own question to the
> > list:
> >
> > Okay, I did the same.  That's what we're here for. :-)  Though I admit
all
> > the semantics and ridiculous claims and scenarios are really just
wasting
> > everyone's time.
> >
> > >   What are your ten top criteria's for evaluating a tool (program,
> > service,
> > > protocol, etc) in terms of security?
> >
> > That's too broad.  There's too many variables involved.  You have to
test
> > and check everything from how it's run, to the user it runs as, what it
> > accepts for input, what it outputs, how it functions, if it creates any
> temp
> > files and so on... the purpose intended for it to serve and so, so much
> > more.
> >
> > > Is the amount of coverage on SF your only one?
> >
> > Heck no.
> >
> > > What about product support?
> >
> > For my own programs or for one's I use?
> >
> > > Vendor history?
> >
> > Certainly, though product history of the program I'd be using would be
> just
> > as or more important, assuming it's open source and I can see, review
and,
> > if need be, modify the source.
> >
> > > Open source vs. closed source?
> >
> > I would never, ever, use closed source given a choice.  I do on my home
> PC,
> > but not anything that would run an Internet service.
> >
> > > Corporate policy?
> >
> > That depends on the policies.  The most secure program/service is the
> > ultimate goal.  I'm not sure how policies would change that, other than
a
> > manager refusing to use something they haven't used before or whatever,
> and
> > that is something you can try and change but may not be able to.  I'd
just
> > not get in a situation like that or work with some company that didn't
> have
> > common sense.
> >
> > > Cost?
> >
> > Not an issue, I use open source software personally, so I can see how
it's
> > coded/built and review the code and modify it if need be.  No, that
> doesn't
> > mean I think all closed source programs are a bad thing, I just do a
great
> > deal of things and never needed to go with that alternative.
> >
> > > Vendor reputation? ???
> >
> > Of course.
> >
> > > Do you even have a formal set of criteria's that a
> > > tool must meet in terms of security or do the bean counters make the
> > > decisions for you?
> >
> > Use what's the most secure in regards to history of the product and
review
> > the code, configure and run it as securely as you can and so on... that
is
> > all that can be done.  What about creating your own programs, so you
don't
> > have to relay on people finding exploits that shouldn't exist if a coder
> > used common sense with information that has been available and out  and
> > public for decades?
> >
> > > //I have my anti-flame suit on too so fire away
> >
> > Sweet.
> >
> > >
> > > Vic Parat, Sr. Security Architect
> > > Network Systems Security, LLC
> > > www.nssecurity.com
> >
> > Security firm...? Seriously?  If so, why in the world would you be
arguing
> > the points you did above?  I don't mean to sound like a jerk, but I
don't
> > get it...
> > --
> > Regards,
> > Tim Greer  [EMAIL PROTECTED]
> > Server administration, security, programming, consulting.
> >
> > >
> > > ----- Original Message -----
> > > From: "Tim Greer" <[EMAIL PROTECTED]>
> > > To: "Vic Parat (NSS)" <[EMAIL PROTECTED]>; "Chris Berry"
> > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> > > <[EMAIL PROTECTED]>
> > > Sent: Wednesday, July 02, 2003 10:31 AM
> > > Subject: Re: Ten least secure programs
> > >
> > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Vic Parat (NSS)" <[EMAIL PROTECTED]>
> > > > To: "Chris Berry" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> > > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > > Sent: Tuesday, July 01, 2003 12:28 AM
> > > > Subject: Re: Ten least secure programs
> > > >
> > > >
> > > > > I would definitely question some of your choices (is Apache more
> > secure
> > > > than
> > > > > IIS?)
> > > >
> > > > Yes, very much. :-)
> > > >
> > > > > but I think top honors for "the ten least secure computer items"
is
> an
> > > > > under qualified system administrator.
> > > >
> > > > I agree 100%.  This is also why all the programs mentioned as
insecure
> > > too,
> > > > those pesky humans!
> > > >
> > > > Anyway, while I agree with you, the fact remains that the programs
> > > > themselves differ from problems, one more so than the others.
Surely
> a
> > > > secured Windows server is more secure than a non-secured Linux
server,
> > but
> > > > that's sort of a strange argument to make.
> > > >
> > > > This thread is about insecure programs, nothing more, nothing less.
> > > > Sometimes they are more insecure than others due to a common
> > configuration
> > > > error or default setting and that comes down to a lame sys admin.
> > Really
> > > > though, how many people are really even qualified sys admins?
> > > >
> > > > Anyway, the point being, some programs are far more exploitable, in
> > their
> > > > default or highly configured state, than others... when comparing
them
> > as
> > > > default to each other, as well as configured well, to each other.
> Then,
> > > > comparing them.  Also, mind the fact that depending on what you're
> > talking
> > > > about, some of them don't allow you to have the control to configure
> > them
> > > > and are thus insecure.
> > > >
> > > > For example, Windows only allows to much.  There's a lot you can do,
> but
> > > > mostly a lot you can not.  Whereas a Linux of FreeBSD system, you
have
> > > much
> > > > more you can do, right down into hacking the kernel however you
want,
> > and
> > > > even if far more involved of a process and much more skills needed,
> it's
> > > up
> > > > to the person and their skills to configure, hack and use their
skills
> > to
> > > > make the server/system far more secure than say a Windows system
> doesn't
> > > > allow.
> > > >
> > > > Personally, I find that a default Windows set up is about as
insecure
> as
> > a
> > > > default Linux set up.  Both need to have a lot done, but you can do
a
> > lot
> > > > more with a Linux  system.  Do most people have the time, let alone
> the
> > > > comprehension?  Surely not, so we go back to your comment about
> > > unqualified
> > > > sys admins.  I couldn't agree more.  However, two qualified sys
admins
> > > > skilled in their respective areas, the Linux sys admin can do more,
> > unless
> > > > that Windows sys admin is privileged enough to be offered the
Windows
> > > source
> > > > code to review and modify to locate and close any potential holes.
> > > > --
> > > > 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
----------------------------------------------------------------------------

Reply via email to