Message-ID: <20031204015816.GGYA317816.fep04-mail.bloor.is.net.cable.rogers.com@BillDell>
From: full-disclosure at royds.net (Bill Royds)
Subject: automated vulnerability testing

 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@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Michael Gale
Sent: December 2, 2003 12:34 AM
To: full-disclosure@...ts.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@...ternet.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

Powered by blists - more mailing lists