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
> 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 th
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 (
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 ari
ftware 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
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, o
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
> 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 handl
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 othe
[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
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 m
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
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.
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
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 majo
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 addictio
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
>> [...] 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
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
19 matches
Mail list logo
