RE: [Full-Disclosure] automated vulnerability testing

From: Bill Royds (full-disclosure_at_royds.net)
Date: 12/04/03

  • Next message: KF: "Re: [Full-Disclosure] flames security group start to play , yet another vuln found (rustymemory and welshboi)" 
    To: "'Michael Gale'" <michael@bluesuperman.com>, <full-disclosure@lists.netsys.com>
Date: Wed, 3 Dec 2003 21:00:05 -0500

     Yes, whether a particular program is secure is ultimately the problem of
    the choices of a programmer. And one of those choices is the choice of
    programming language. As I said before, it takes a good programmer to
    program securely in C because C requires the programmer to more housekeeping
    to keep track of variable usage, pointer validity, array size, string size,
    buffer size, stack size argument matching, etc. than other programming
    languages. A programming god can do it and they can write secure code in C.
       But nearly all programmers are not programming gods but just mortals. So
    they can't keep track of all the details of security that C requires more
    than other languages. Programs written in C are more likely to be insecure
    than in other languages because these other languages don't have strings
    with unlimited possible size, have proper arrays and bounds checks on them,
    have garbage collection (or at least allocation lifetime tracking) etc. It
    takes a lot more work to write secure C code than practically any other
    language even if one can write secure C. That is why I said that if someone
    intends their code to be secure, they will choose another programming
    language. The use a tool that can help them with security, not require a lot
    of extra work to be secure.
      It is a bit of a vicious circle. Since most software is written in C,
    every one learning programming learns to program in C. But that just
    perpetuates the dominance of C. C is to programming languages as Microsoft
    is to OS. It creates a monoculture where the design flaws of the language
    get perpetuated into the design flaws of all the programs written in that
    language.
       Oh, I have been programming in C since 1974, when I used one of the first
    Unices on a PDP11-45. I have a first edition of Kernigan and Ritchie and I
    like using it. But I recognize its limitations.

    -----Original Message-----
    From: full-disclosure-admin@lists.netsys.com
    [mailto:full-disclosure-admin@lists.netsys.com] On Behalf Of Michael Gale
    Sent: December 2, 2003 12:34 AM
    To: full-disclosure@lists.netsys.com
    Subject: Re: [Full-Disclosure] automated vulnerability testing

    Ok -- I am by far NOT a programmer but I have been doing system
    administration for some time for software companies. From my experience
    it is the programmer not the language that makes a program what it is.

    If the program is not secure or highly exploitable then that is a fault
    of the programmer not the language.

    Blaming C or C++ for not securing the code for you or providing you with
    to much power is ridiculous.

    That is like blaming a car manufacture because your car has to much
    horsepower and you were going to fast and hit poll.

    Programming is like driving - YOU are behind the wheel and in control.
    If you can not handle it try a 3 cyclinder car and basic HTML :)

    Michael.

    On Mon, 1 Dec 2003 09:58:33 -0600 (CST)
    Ron DuFresne <dufresne@winternet.com> wrote:

    > On Sun, 30 Nov 2003, Jonathan A. Zdziarski wrote:
    >
    > >
    > > > Aren't such measures -- especially the former -- simply crutches
    > > > that effectively _encourage_ the continuation of poor (even
    > > > downright negligent) programming practices?
    > >
    > > Only to the extent that TCP wrappers and firewalls are simply
    > > crutches to effectively encourage the continuation of poor systems
    > > administration.
    > >
    > >
    >
    > Quite a flaw in logic there, I'm sure you meant;
    >
    > Only to the extent that TCP wrappers and firewalls are simply crutches
    > to effectively encourage the continuation of poor systems networking
    > protocols that already exist.
    >
    >
    > Being that the flaws are inherent to the network protocols in use.
    > Admins have long known how to lock a system down, and keep it that
    > way, remove all users and limit access and functionality. That tends
    > to make the system far less then useful. But, the core issue lies
    > with the networking protocools that are meant to make iintersystem
    > communications actually happen. There was no security within their
    > design, security was the lowest factor in the developers mind at the
    > time. And of course a rewrite of all that code and then pushing that
    > to the internet-citezenry at large would be fairly daunting eh? Look
    > how well the conversion from ssh1 to ssh2 has progressed...
    >
    >
    > Thanks,
    >
    > Ron DuFresne
    >
    > _______________________________________________
    > Full-Disclosure - We believe in it.
    > Charter: http://lists.netsys.com/full-disclosure-charter.html

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: KF: "Re: [Full-Disclosure] flames security group start to play , yet another vuln found (rustymemory and welshboi)"