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

2004-06-09 Thread 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 handl

RE: [SC-L] Interesting article on the adoption of Software Security

2004-06-09 Thread John Steven

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

2004-06-09 Thread 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 othe

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

2004-06-09 Thread 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

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

2004-06-09 Thread 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 m

[SC-L] Determina claims 100% protection against all buffer overflows

2004-06-09 Thread Thor Larholm
Startup Determina has released a product that they claim protects against 100% of all memory based attacks, including all types of buffer overflows, without any false positives, false negatives or noticeable overhead. This is appareantly based on work done by their CTO, Dr. Saman Amarasinghe, who

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

2004-06-09 Thread 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

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

2004-06-09 Thread 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.

[SC-L] RE: Determina claims 100% protection against all buffer overflows

2004-06-09 Thread Thor Larholm
Aha, here are some more details about Saman's publications. http://cag-www.lcs.mit.edu/~saman/cv.html#PUBLICATIONS And this one could look like the paper they based all of SecureCore on: "Secure Execution Via Program Shepherding" http://cag.lcs.mit.edu/commit/papers/02/RIO-security-usenix.pdf

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

2004-06-09 Thread 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

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

2004-06-09 Thread 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 majo

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

2004-06-09 Thread 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 addictio

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

2004-06-09 Thread 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

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

2004-06-09 Thread 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

Re: [SC-L] Interesting article on the adoption of Software Security

2004-06-09 Thread Florian Weimer
* Kenneth R. van Wyk: > There's an interesting article out on Net-Security.org (see the full article > at http://www.net-security.org/article.php?id=697) that addresses why > software development organizations adopt (or do not adopt) a Software > Security development methodology. Check it out