Re: Ten least secure programs
From: Tim Greer (chatmaster_at_charter.net)
To: "Vic Parat (NSS)" <email@example.com>, "Chris Berry" <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com> Date: Wed, 2 Jul 2003 12:46:26 -0700
----- Original Message -----
From: "Vic Parat (NSS)" <firstname.lastname@example.org>
To: "Tim Greer" <email@example.com>; "Chris Berry"
<firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org>;
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
> to do.
> 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
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.
> 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
> 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
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
> What are your ten top criteria's for evaluating a tool (program,
> 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
> Is the amount of coverage on SF your only one?
> 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
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? ???
> 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
> Vic Parat, Sr. Security Architect
> Network Systems Security, LLC
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
-- Regards, Tim Greer email@example.com Server administration, security, programming, consulting. > > ----- Original Message ----- > From: "Tim Greer" <firstname.lastname@example.org> > To: "Vic Parat (NSS)" <email@example.com>; "Chris Berry" > <firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org>; > <email@example.com> > Sent: Wednesday, July 02, 2003 10:31 AM > Subject: Re: Ten least secure programs > > > > > > > > ----- Original Message ----- > > From: "Vic Parat (NSS)" <firstname.lastname@example.org> > > To: "Chris Berry" <email@example.com>; <firstname.lastname@example.org>; > > <email@example.com>; <firstname.lastname@example.org> > > 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@example.com > > 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 ----------------------------------------------------------------------------