Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-25 Thread Andy Steingruebl
Ok, so your point then is that a desire for type-safety influenced the hardware architecture of these machines. Fair enough, though I don't know enough of the history of these machines to know how accurate it is. But how can I doubt you Gary? :) I was mainly reflecting in my comments though

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-25 Thread Gary McGraw
Hi Andy, The code/data mix is certainly a problem. Also a problem is the way stacks grow on many particular machines, especially with common C/C++ compilers. You noted a Burroughs where things were done better. There are many others. C is usually just a sloppy mess by default. Language

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-25 Thread Andy Steingruebl
On Wed, Mar 25, 2009 at 10:18 AM, ljknews ljkn...@mac.com wrote: Worry about enforcement by the hardware architecture after you have squeezed out all errors that can be addressed by software techniques.\ Larry, Given the focus we've seen fro Microsoft and protecting developers from

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-25 Thread ljknews
At 1:00 PM -0700 3/25/09, Andy Steingruebl wrote: On Wed, Mar 25, 2009 at 10:18 AM, ljknews mailto:ljkn...@mac.comljkn...@mac.com wrote: Worry about enforcement by the hardware architecture after you have squeezed out all errors that can be addressed by software techniques.\ Larry,

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-24 Thread Andy Steingruebl
On Mon, Mar 23, 2009 at 7:22 AM, Gary McGraw g...@cigital.com wrote: hi guys, I think there is a bit of confusion here WRT root problems. In C, the main problem is not simply strings and string representation, but rather that the sea of bits can be recast to represent most anything. The

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-22 Thread Jim Manico
...@securecoding.org; Benjamin Tomhave list-s...@secureconsulting.net; Secure Code MailingList SC-L@securecoding.org Sent: Friday, March 20, 2009 10:37 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT) John Stevens for Cyber Czar! I have Elect J.Stevens bumper stickers

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-21 Thread Gary McGraw
hi pub, once long ago I spilt a bottle of wine with dan geer in Palo Alto to lament his dead disk drive. we decided the conference sucked anyway and proceeded to the Cowper. we argued for hours about whether a buffer overflow was a bug or a flaw. if you find one in a code pile (say, caused

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-21 Thread Gunnar Peterson
Two areas that don't seem to immediately lend themselves to design/ spec level solutions are (1) transitive trust and (2) interaction errors between multiple components that are all working correctly. I'd love to hear from people who've had to solve these problems in the real world.

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-21 Thread Florian Weimer
* Steven M. Christey: Two areas that don't seem to immediately lend themselves to design/spec level solutions are (1) transitive trust and (2) interaction errors between multiple components that are all working correctly. I'd love to hear from people who've had to solve these problems in the

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-20 Thread Pravir Chandra
Well, it seems that there's an interesting nuance here. We don't really have a concrete definition for what software is (code, design, compiled bins, etc.). All of these things plus the subjective expectations from designers, users, and security folks tend to be the domain for how the term is