RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[David Crocker]

ljknews wrote:

>>
And there are ways of using Assembly Language to avoid pitfalls that it
provides.  There are ways of using horse-drawn carriages to avoid the
major reason (think street cleaning) why the automobile was embraced in
urban areas during the early part of the 20th century.

What there are _not_ are reasons for new development to cling to languages
which make flawed constructs easy for the individual programmer to misuse.
<<

There is often one very good reason for clinging to such languages: because
there is no other suitable language available. As has already been pointed out,
there is usually very little alternative to C/C++ when it comes to kernel mode
code.

I would love to see a safer alternative to C/C++ for writing operating system
kernels, device drivers and real-time embedded applications (yes, I know Ada can
be used for the latter, buts its package structure and associated "with-ing"
problem can be a real pain in large systems). The newer programming languages
such as Java, C# and Eiffel are all designed for applications and make heavy use
of garbage collection (which is a boon to application writers, but a no-no for
kernel code and many embedded apps).

What I don't understand is why the language standardisation committees don't
remove some of the unsafe dross when they bring out new language revisions. A
classic example is the failure to define the type of a string literal in C as
"const char*". Just imagine if we had a new version of C++ with all the unsafe
stuff removed. Backwards compatibility would not be a problem in practice,
because the compiler suppliers would provide switches to make their new
compilers accept obsolete constructs.

As for non-real-time application-level code, I gave up writing them in C++ by
hand long ago. [Actually I prefer to write specifications, verify them, and let
a code generator produce correct C++ from them; but that is another story.]

David Crocker
Consultancy & contracting for dependable software development
www.eschertech.com

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[der Mouse]

> What there are _not_ are reasons for new development to cling to
> languages which make flawed constructs easy for the individual
> programmer to misuse.

Certainly there are - or people wouldn't be doing it.

Whether you or I think those reasons are good reasons is another
question.  (Some of the most obviously plausible: it's what the
programmers know; it's what the target sytem supports; it's necessary
to interface to some externally-supplied libraries)

/~\ The ASCII   der Mouse
\ / Ribbon Campaign
 X  Against HTML   [EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[ljknews]

At 10:36 PM +0100 6/10/04, David Crocker wrote:
>I agree that converting legacy code to use one of the techniques I suggest isn't
>always going to be easy and inexpensive. My posting was aimed at those saying
>that something better than C/C++ should be used for new security-critical
>applications (which I agree is preferable), and I was pointing out that there
>are ways of using C++ so as to avoid its troublesome "array=pointer" feature.

And there are ways of using Assembly Language to avoid pitfalls that it
provides.  There are ways of using horse-drawn carriages to avoid the
major reason (think street cleaning) why the automobile was embraced in
urban areas during the early part of the 20th century.

What there are _not_ are reasons for new development to cling to languages
which make flawed constructs easy for the individual programmer to misuse.

(Of course rewriting existing applications from one language to another
should only be undertaken when there are strong reasons for rewriting
in general, since the defects introduced, regardless of language, will
be many.)

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Crispin Cowan]

David Crocker wrote:
Apart from the obvious solution of choosing another language, there are at least
two ways to avoid these problems in C++:
1. Ban arrays (to quote Marshall Cline's "C++ FAQ Lite", arrays are evil!). Use
...
2. If you really must have naked arrays, ban the use of indexing and arithmetic
on naked pointers to arrays (i.e. if p is a pointer, then p[x], p+x, p-x, ++p
 

If you want safer C and you want the compiler to enforce it, and you 
don't mind having to re-write your code some, then use one of the safer 
C dialects (CCured  and Cyclone 
). These tools provide a 
nice mid-point in the amount of work you have to do to reach various 
levels of security in C/C++:

   * low security, low effort
 o do nothing
 o code carefully
 o apply defensive compilers, e.g. StackGuard
 o apply code auditors, e.g. RATS, Flawfinder
 o port code to safer C dialects like CCured and Cyclone
 o re-write code in type safe languages like Java and C#
 o apply further code security techniques, e.g. formal theorem
   provers WRT a formal spec
   * high security, high effort
Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com

RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[David Crocker]

I agree that converting legacy code to use one of the techniques I suggest isn't
always going to be easy and inexpensive. My posting was aimed at those saying
that something better than C/C++ should be used for new security-critical
applications (which I agree is preferable), and I was pointing out that there
are ways of using C++ so as to avoid its troublesome "array=pointer" feature.

Converting legacy code so as to conform to my second suggested style may be
worthwhile if the code is known to have buffer overrun problems that need to be
addressed. The normal solution would likely involve adding an extra "buffer
limit" parameter to many functions that take a pointer to a buffer as a
parameter. Changing the type of the buffer pointer from "X*" to "Array" (or
from "const X*" to "ConstArray") is no more difficult and leads to clearer
code. The semantics of Array mimic those of X*, so very little extra code
need be written, apart from introducing the buffer overflow checks where they
are needed, and changing each initialisation of the form "X* x = a" (where a is
an array of length n) to "Array x (a, n)" to initialise the limit part as
well.

As for system calls that use arrays, these are indeed a problem if using STL
classes instead of arrays, but not if the Array and ConstArray classes are used
to regulate access to ordinary arrays. As for unsafe system calls, the
documentation of any system or library call should include a guaranteed maximum
value it will use as an index into the array parameter it is given, and a check
can be inserted prior to the call that the buffer is large enough. System or
library calls that provide no such guarantee (such as "gets" in the ANSI C
library) must never be used.

Of course, there are many other flaws in C and C++ and I advocate applying the
MISRA-C rules (other than Rule 1 if using C++) as well, together with additional
rules to avoid some other dangerous features of C++.

David Crocker
Consultancy & contracting for dependable software development
www.eschertech.com



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Jared W. Robinson
Sent: 10 June 2004 17:13
To: [EMAIL PROTECTED]
Subject: Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness


On Wed, Jun 09, 2004 at 03:34:52PM +0100, David Crocker wrote:
> Apart from the obvious solution of choosing another language, there are at
least
> two ways to avoid these problems in C++:
>
> 1. Ban arrays (to quote Marshall Cline's "C++ FAQ Lite", arrays are evil!).
Use
> classes from the STL, or another template library instead. Arrays should be
used
> only in the template library, where their use can be controlled.
>
> 2. If you really must have naked arrays, ban the use of indexing and
arithmetic
> on naked pointers to arrays (i.e. if p is a pointer, then p[x], p+x, p-x, ++p
> and --p are all banned). Instead, refer to arrays using instances of a
template
> class "Array" that encapsulates both the pointer (an X*) and the limit (an
> unsigned int).

Unfortunately, I don't think this advice will work for many projects.

First, Many programs must make system calls that only use arrays.
Some of those calls are unsafe.

Second, There is a lot of "legacy" code written with the error-prone
array indexing that you condemn. While the code must be maintained,
changing it introduces risks of new bugs that lead to instability, and
many people aren't willing to take that risk. So I think your advice
to ban arrays could only be applied to new code, and new projects.
Either that, or the conversion must be made gradually, and must be timed
at the right stage of a maintenance cycle.

- Jared

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Jared W. Robinson]

On Wed, Jun 09, 2004 at 03:34:52PM +0100, David Crocker wrote:
> Apart from the obvious solution of choosing another language, there are at least
> two ways to avoid these problems in C++:
> 
> 1. Ban arrays (to quote Marshall Cline's "C++ FAQ Lite", arrays are evil!). Use
> classes from the STL, or another template library instead. Arrays should be used
> only in the template library, where their use can be controlled.
> 
> 2. If you really must have naked arrays, ban the use of indexing and arithmetic
> on naked pointers to arrays (i.e. if p is a pointer, then p[x], p+x, p-x, ++p
> and --p are all banned). Instead, refer to arrays using instances of a template
> class "Array" that encapsulates both the pointer (an X*) and the limit (an
> unsigned int).

Unfortunately, I don't think this advice will work for many projects.

First, Many programs must make system calls that only use arrays.
Some of those calls are unsafe.

Second, There is a lot of "legacy" code written with the error-prone
array indexing that you condemn. While the code must be maintained,
changing it introduces risks of new bugs that lead to instability, and
many people aren't willing to take that risk. So I think your advice
to ban arrays could only be applied to new code, and new projects.
Either that, or the conversion must be made gradually, and must be timed
at the right stage of a maintenance cycle.

- Jared

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Blue Boar]

ljknews wrote:
Okay, that's a bold statement.  I'd better back it up.  If you have a
string-handling library of any kind, someone's going to come up with a
program design that builds a twenty character string for a person's name,
putting first name in the first ten characters, and last name in the last
ten characters.  Eric Smith changes his first name to Navratilova, and he's
suddenly listed by the program as "Navratilovamith amith" - buffer overflow.
Sure, it doesn't overflow into the stack, but it overflows into important
data.
How does the buffer overflow "into important data" using "any language" ?
With Ada and Pascal a 20 character array just has no syntax for storing
a character into the 21st position.  While it is true you will get a
(possibly unanticipated) runtime exception rather than pleasing results,
there is no opportunity for pleasing results in this situation.  The
clever programmer may add an exception handler to display a user friendly
message like "get a name change" rather than the default "index out of
bounds" or whatever.  But neither the clever nor the lazy programmer
gets an overflow "into important data".  The boundary condition is
detected and prevented from causing totally obscure failures.
I think you failed to parse the example provided.  He gave an example 
where he has imposed an arbitrary structure on the built-in string, and 
violated it.  I think he blew the example, as I'm reading it.  I *think* 
he meant:

"Eric  Smith "
becomes
"Navratilovamith "
Thereby blowing his "buffer", and maybe screwing the rest of the program 
logic.  He didn't overflow at the string class level, he did so at the 
logic level.  Or his derived string class, or however you like to think 
of it.

BB

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[der Mouse]

> Sure, it doesn't overflow into the stack, but it overflows into
> important data.  And if you want to go further into insanity, you can
> manufacture a case where character 11 being lower case causes
> unwanted code to be executed (no default condition in a 'case'
> statement, no good error handling, etc).

This is not as far-fetched as you make it sound.  I actually ran into
something not too dissimilar in the wild.

Back in the late '80s, I had the dubious pleasure of tracking down the
bug responsible for a mail UA breaking overnight, on a machine that was
completely untouched - nothing at all had run, not even (the local
equivalent of) cron jobs.

It turned out to break as soon as the day number had two digits in a
month whose full name was only three characters long.  It broke
overnight between May 9 and May 10.

Y'see, what happened was, one piece of code formatted the date in the
form "Fullmonthname DD" - two-digit day, with a leading space for days
1 through 9, and the month name in full.  Then another piece of code
converted this to the short form by skipping three characters in,
dropping a terminator, looking for the next space, and picking up the
day number from there.  Most months, this worked fine.  May 1 through
9, it worked, because the leading space on the day number stopped the
scan.  But May 10, the 10 was mistaken for the rest of the month name,
the parser got confused, and things went downhill from there.

/~\ The ASCII   der Mouse
\ / Ribbon Campaign
 X  Against HTML   [EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[ljknews]

At 10:02 AM -0500 6/9/04, Alun Jones wrote:

>I did some work recently on .NET Security, trying to come up with some
>examples that would demonstrate how you'd screw it up in code.  It's
>certainly difficult to come up with bad examples that aren't needlessly
>bone-headed, but when you look at other people's code, you realise that an
>awful lot of programmers are bone-headed.  Buffer overflows can happen in
>any language, no matter what those languages do to prevent them.
>
>Okay, that's a bold statement.  I'd better back it up.  If you have a
>string-handling library of any kind, someone's going to come up with a
>program design that builds a twenty character string for a person's name,
>putting first name in the first ten characters, and last name in the last
>ten characters.  Eric Smith changes his first name to Navratilova, and he's
>suddenly listed by the program as "Navratilovamith amith" - buffer overflow.
>Sure, it doesn't overflow into the stack, but it overflows into important
>data.

How does the buffer overflow "into important data" using "any language" ?

With Ada and Pascal a 20 character array just has no syntax for storing
a character into the 21st position.  While it is true you will get a
(possibly unanticipated) runtime exception rather than pleasing results,
there is no opportunity for pleasing results in this situation.  The
clever programmer may add an exception handler to display a user friendly
message like "get a name change" rather than the default "index out of
bounds" or whatever.  But neither the clever nor the lazy programmer
gets an overflow "into important data".  The boundary condition is
detected and prevented from causing totally obscure failures.

RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Alun Jones]

[EMAIL PROTECTED] <> wrote on Wednesday, June 09, 2004 7:58
AM: 
> Although I am in favor of languages that help prevent such nasties as
> input buffer overruns, this is an excellent point.  A sloppy
> programmer will write sloppy code.  Reminds me of an old saying that I
> heard years
> ago while studying mechanical engineering: a determined
> programmer can
> write a FORTRAN program in ANY language.  :-)  (Well, notwithstanding
> FORTRAN's built-in ability of handling complex numbers, but I
> digress...) 

Going back over some of my old FORTRAN code, I find that I was writing
object-oriented code in FORTRAN.  Going over other people's C++ code, I can
see that they're trying to make it work like FORTRAN, or QuickBASIC, or
something like that.

I did some work recently on .NET Security, trying to come up with some
examples that would demonstrate how you'd screw it up in code.  It's
certainly difficult to come up with bad examples that aren't needlessly
bone-headed, but when you look at other people's code, you realise that an
awful lot of programmers are bone-headed.  Buffer overflows can happen in
any language, no matter what those languages do to prevent them.

Okay, that's a bold statement.  I'd better back it up.  If you have a
string-handling library of any kind, someone's going to come up with a
program design that builds a twenty character string for a person's name,
putting first name in the first ten characters, and last name in the last
ten characters.  Eric Smith changes his first name to Navratilova, and he's
suddenly listed by the program as "Navratilovamith amith" - buffer overflow.
Sure, it doesn't overflow into the stack, but it overflows into important
data.  And if you want to go further into insanity, you can manufacture a
case where character 11 being lower case causes unwanted code to be executed
(no default condition in a 'case' statement, no good error handling, etc).

> IMHO, the bottom line is that there's no excuse for sloppiness and a
> strong language can only do so much to prevent the programmer from
> his/her own sloppiness. 

The first defence against unsecure coding is to hire and educate your
developers in such a way as to exclude the unsecure coding practices.  It's
not the only defence - but it's the first you're going to need, because if
you don't have that, you've got programmers who will flout security
prevention measures _because_ they don't understand how to do it properly,
or why they're being strong-armed in a particular direction.

And on the topic of hiring better programmers, I'm now in my third week as
[EMAIL PROTECTED]  [But my personal address remains this one]

Alun.

RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[David Crocker]

Sloppy coding can be done in any language, but C and C++ have 3 features that
aggravate the problem:

1. The "array=pointer" idiom. Given a parameter which is an array, you can't ask
at run-time how big the array is - you have to do extra work and pass the size
in an additional parameter (whereas most languages pass the size of an array
automatically as part of the array). So doing buffer overflow checks requires
more than just inserting the check - you have to make sure that an extra "array
size" parameter is passed all the way down the call stack. [C and C++ cannot be
considered strongly typed, in part because of the lack of distinction between
pointers and arrays].

2. By permitting pointer arithmetic, C and C++ encourage you to pass a pointer
into the middle of a buffer, rather than passing the [start of the] buffer and
an index into it, which makes bounds checking even more tedious to do (you have
to pass a pointer to one-past-the-end-of-the-array as well, and even then this
is less useful than having an index and a limit).

3. The lack of automatic bounds checking. Of course, run-time bounds checking is
by no means a complete solution, but it does at least prevent a buffer overflow
being used as a security attack, turning it into a denial-of-service attack
instead.

Apart from the obvious solution of choosing another language, there are at least
two ways to avoid these problems in C++:

1. Ban arrays (to quote Marshall Cline's "C++ FAQ Lite", arrays are evil!). Use
classes from the STL, or another template library instead. Arrays should be used
only in the template library, where their use can be controlled.

2. If you really must have naked arrays, ban the use of indexing and arithmetic
on naked pointers to arrays (i.e. if p is a pointer, then p[x], p+x, p-x, ++p
and --p are all banned). Instead, refer to arrays using instances of a template
class "Array" that encapsulates both the pointer (an X*) and the limit (an
unsigned int). Such an object needs only 2 words of storage (compared to 1 word
for a naked pointer), so it can assigned and passed by value. You can provide an
operator to return the value of the limit, and an indexing operator (with
optional bounds checking). If you really must, you can even implement "pointer
arithmetic" operators for the class which update the limit at the same time as
updating the pointer.

David Crocker
Consultancy & contracting for dependable software development
www.eschertech.com

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[David Eisner]

der Mouse wrote:

>All that a "better" language will bring you in this regard is that it
>will (a) push the sloppiness into places the compiler can't check and
>(b) change the ways things break when confronted with input beyond the
>design underlying their code.
>  
>

My car has a tether connected to the gas cap.  This prevents
me from leaving the cap on top of my car when I drive away.

My car won't let me lock my doors unless I'm outside of the
car holding my keys.  This makes it much more difficult to
lock my keys in the car.  Yes, I've given up some control,
but the trade-off is worth it, in my opinion.

These features mitigate the harm my absentmindedness can
lead to.  I'm still absentminded.  I can still leave my
sunroof open (I did, and, yes, it rained).   Even so, I'm
glad those features are there.

-David

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[ljknews]

At 9:11 AM -0400 6/9/04, Gary McGraw wrote:
>Language makes a huge difference, eapecially in the realm of bugs.  So not using C 
>and C++ is smart.  Use Java or C# instead.

Or Ada, or PL/I, or Pascal, or Eiffel, etc.

There are _lots_ of choices out there.

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Gary McGraw]

Language makes a huge difference, eapecially in the realm of bugs.  So not using C and 
C++ is smart.  Use Java or C# instead.  But poor programmers can, in fact, screw up in 
type safe languages as well.  One major problem can be seen in the design flaw 
category of defects.

Studies show that the split between bugs and flaws is 50/50.  That means language 
choice is important but will not solve the problem.

gem

 -Original Message-
From:   Kenneth R. van Wyk [mailto:[EMAIL PROTECTED]
Sent:   Wed Jun 09 09:06:48 2004
To: [EMAIL PROTECTED]
Subject:Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

der Mouse wrote:
>All that a "better" language will bring you in this regard is that it
>will (a) push the sloppiness into places the compiler can't check and
>(b) change the ways things break when confronted with input beyond the
>design underlying their code.

Although I am in favor of languages that help prevent such nasties as 
input buffer overruns, this is an excellent point.  A sloppy programmer 
will write sloppy code.  Reminds me of an old saying that I heard years 
ago while studying mechanical engineering: a determined programmer can 
write a FORTRAN program in ANY language.  :-)  (Well, notwithstanding 
FORTRAN's built-in ability of handling complex numbers, but I digress...)

IMHO, the bottom line is that there's no excuse for sloppiness and a 
strong language can only do so much to prevent the programmer from 
his/her own sloppiness.

Cheers,

Ken van Wyk
http://www.KRvW.com





This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.

RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Peter Amey]

der Mouse (Maus surely?) wrote
[snip]
> 
> Well, actually, but for the world's addiction to sloppy coding.
> 
> It's entirely possible to avoid buffer overflows in C; it 
> just requires
> a little care in coding.  C's major failing in this regard - and I
> don't actually consider it all that major - is that it doesn't provide
> any tools to help.  It assumes that you the programmer know 
> what you're
> doing, and the mismatch between that and the common reality is where
> the problem actually comes from.


I dislike this commonly-used argument that essentially says "you should only employ 
above average people who don't make mistakes".  It is flawed on lots of levels.

1.  On average ability over our industry is average!
2.  Even brilliant, infallible programmers like me make mishtukes shummtimes.
3.  Even if above average, non-sloppy programmers can avoid mistakes, the effort they 
spend doing so is a distraction from their real job of solving the problem the program 
is intended for.
4.  The levels of mental abstraction needed to solve an application domain problem and 
to worry about operator precedence and buffer overflow are completely different; there 
is good evidence that humans don't work well at more than one abstraction level at a 
time.

> 
> All that a "better" language will bring you in this regard is that it
> will (a) push the sloppiness into places the compiler can't check and
> (b) change the ways things break when confronted with input beyond the
> design underlying their code.
> 

This sounds like the Syrius Cybernetics defence (from the Hitch Hiker's Guide to the 
Galaxy);  essentially you seem to be saying it is OK if all the deep and complex flaws 
in a product are completely obscured by all the shallow and obvious ones.  You can't 
assume that the sloppy programmer in C /only/ introduces shallow errors.

In practice, well designed languages can do much more than you claim.  They can 
completely eliminate whole classes of error that currently exercise our attention, 
make sloppiness very hard to conceal and make it much easier to find any subtle errors 
that remain.

Peter


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.  The IT Department at Praxis Critical Systems can be contacted at 
[EMAIL PROTECTED]
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**



This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[ljknews]

At 4:20 PM -0400 6/8/04, der Mouse wrote:
>>> [...] the majority of computer security holes are buffer overruns.
>>> These would be minor irritations but for the world's addiction to
>>> the weakly typed programming languages C and its derivative C++.
>
>Well, actually, but for the world's addiction to sloppy coding.
>
>It's entirely possible to avoid buffer overflows in C; it just requires
>a little care in coding.  C's major failing in this regard - and I
>don't actually consider it all that major - is that it doesn't provide
>any tools to help.  It assumes that you the programmer know what you're
>doing, and the mismatch between that and the common reality is where
>the problem actually comes from.

It is _possible_ to write a correct program in Machine Code,
however a good number of years ago some people (wisely, from my
perspective) decided that automating the correctness effort was
a good idea and Assembly Language was born (over and over again
for various architectures).

This trend was repeated with the advent of Compiled Languages,
intended to describe the problem space more than the machine
space.  There are successive improvements in this automation
of defect avoidance, but some developers have chosen to stop
at a rather weak point in the evolution.

>All that a "better" language will bring you in this regard is that it
>will (a) push the sloppiness into places the compiler can't check and

Not at all.  The "sloppiness into places the compiler can't check"
still exists in C-based languages, and while strongly typed languages
cannot help with certain problems they do free the programmer to deal
with those areas while relying on the computer to check those aspects
that _are_ susceptible to automation.

>(b) change the ways things break when confronted with input beyond the
>design underlying their code.

That seems no different from C-based languages.

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Kenneth R. van Wyk]

der Mouse wrote:
All that a "better" language will bring you in this regard is that it
will (a) push the sloppiness into places the compiler can't check and
(b) change the ways things break when confronted with input beyond the
design underlying their code.
Although I am in favor of languages that help prevent such nasties as 
input buffer overruns, this is an excellent point.  A sloppy programmer 
will write sloppy code.  Reminds me of an old saying that I heard years 
ago while studying mechanical engineering: a determined programmer can 
write a FORTRAN program in ANY language.  :-)  (Well, notwithstanding 
FORTRAN's built-in ability of handling complex numbers, but I digress...)

IMHO, the bottom line is that there's no excuse for sloppiness and a 
strong language can only do so much to prevent the programmer from 
his/her own sloppiness.

Cheers,
Ken van Wyk
http://www.KRvW.com

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[der Mouse]

>> [...] the majority of computer security holes are buffer overruns.
>> These would be minor irritations but for the world's addiction to
>> the weakly typed programming languages C and its derivative C++.

Well, actually, but for the world's addiction to sloppy coding.

It's entirely possible to avoid buffer overflows in C; it just requires
a little care in coding.  C's major failing in this regard - and I
don't actually consider it all that major - is that it doesn't provide
any tools to help.  It assumes that you the programmer know what you're
doing, and the mismatch between that and the common reality is where
the problem actually comes from.

All that a "better" language will bring you in this regard is that it
will (a) push the sloppiness into places the compiler can't check and
(b) change the ways things break when confronted with input beyond the
design underlying their code.

Now, admittedly, (b) may be worth doing, other things being equal
(which of course they never really are).  But the basic problem is
sloppy code, not the language in which it's written.  (Well, most of
it.  People do make mistakes - but while some buffer overflows are due
to someone trying to do it right and making a mistake, most of them
come from not even trying.  Limit it to exploitable overflows and the
proportion is even higher.)

/~\ The ASCII   der Mouse
\ / Ribbon Campaign
 X  Against HTML   [EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[ljknews]

At 1:10 PM -0400 6/8/04, Jose Nazario wrote:
>thought some of you may find this editorial from the May 04 ACM Queue
>worth a read. ACM Queue is an interesting magazine and has a website at
>acmqueue.org.
>
>Buffer Overrun Madness
>
>ACM Queue vol. 2, no. 3 - May 2004
>by Rodney Bates, Wichita State University
>
>Why do good programmers follow bad practices?
>
>In January 2003, the Slammer worm was reported to be the fastest spreading
>ever. Slammer gets access by exploiting a buffer overrun. If you peruse
>CERT (Computer Emergency Readiness Team) advisories or security upgrade
>releases, you will see that the majority of computer security holes are
>buffer overruns. These would be minor irritations but for the world's
>addiction to the weakly typed programming languages C and its derivative
>C++.

And yet this mailing list, supposedly devoted to secure coding,
seem polarized around the notion of shoring up those languages.

[SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Jose Nazario]

thought some of you may find this editorial from the May 04 ACM Queue
worth a read. ACM Queue is an interesting magazine and has a website at
acmqueue.org.

Buffer Overrun Madness

ACM Queue vol. 2, no. 3 - May 2004
by Rodney Bates, Wichita State University

Why do good programmers follow bad practices?

In January 2003, the Slammer worm was reported to be the fastest spreading
ever. Slammer gets access by exploiting a buffer overrun. If you peruse
CERT (Computer Emergency Readiness Team) advisories or security upgrade
releases, you will see that the majority of computer security holes are
buffer overruns. These would be minor irritations but for the world's
addiction to the weakly typed programming languages C and its derivative
C++.




jose nazario, ph.d. [EMAIL PROTECTED]
http://monkey.org/~jose/http://infosecdaily.net/