Re: Ten least secure programs

From: Tim Greer (
Date: 07/02/03

  • Next message: Mitch Pirtle: "Re: Ten least secure programs"
    To: "Vic Parat (NSS)" <>, "Chris Berry" <>, <>, <>, <>
    Date: Wed, 2 Jul 2003 12:46:26 -0700

    ----- Original Message -----
    From: "Vic Parat (NSS)" <>
    To: "Tim Greer" <>; "Chris Berry"
    <>; <>; <>;
    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
    > 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.


    > 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

    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,
    > 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?

    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


    > 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
    get it...

    Tim Greer
    Server administration, security, programming, consulting.
    > ----- Original Message -----
    > From: "Tim Greer" <>
    > To: "Vic Parat (NSS)" <>; "Chris Berry"
    > <>; <>; <>;
    > <>
    > Sent: Wednesday, July 02, 2003 10:31 AM
    > Subject: Re: Ten least secure programs
    > >
    > >
    > > ----- Original Message -----
    > > From: "Vic Parat (NSS)" <>
    > > To: "Chris Berry" <>; <>;
    > > <>; <>
    > > 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
    > > 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,
    > > 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
    > > error or default setting and that comes down to a lame sys admin.
    > > though, how many people are really even qualified sys admins?
    > >
    > > Anyway, the point being, some programs are far more exploitable, in
    > > default or highly configured state, than others... when comparing them
    > > 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
    > > about, some of them don't allow you to have the control to configure
    > > 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,
    > > 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
    > > 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
    > > default Linux set up.  Both need to have a lot done, but you can do a
    > > 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,
    > > 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
    > > 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:

  • Next message: Mitch Pirtle: "Re: Ten least secure programs"

    Relevant Pages

    • RE: Internet Connection Wizard failing at Firewall Config and Secure W
      ... Configuration and Secure Web Site Configuration when you run CEICW. ... On the DNS Server, create the DNS Forwarder to forward the external DNS ... 825763 How to configure Internet access in Windows Small Business Server ...
    • Re: Ten least secure programs
      ... that every program out there _must_ be insecure to actually exist. ... can't manage to code a secure program, maybe you should take some courses. ... No security expert would be making such ludicrous ... >> quality of administration skills or configuration. ...
    • Re: Connection string issue when in a separate web.config
      ... permissions for the Secure folder. ... the indexer on .ConnectionStrings expects the name of the connection string, ... the Website->Asp.Net Configuration option in Visual Studio. ...
    • RE: ESX Vmware Physically connected to different segments
      ... If everything is setup properly this configuration should be secure. ... careless admin to connect a vNic to the wrong vSwitch and allow traffic ... This E-Mail transmission ...
    • Re: tomcat server secure ?
      ... Ok, can be secure or not, depending on configuration -- and also on ... >the tomcat server. ...