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

At 1:00 PM -0700 3/25/09, Andy Steingruebl wrote: > 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.\ > > >

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

On Wed, Mar 25, 2009 at 10:18 AM, ljknews 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 mistakes through th

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

At 11:42 AM -0400 3/25/09, Gary McGraw wrote: > 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

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

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 cho

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

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 that

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

s for correlate this data? Or is it, right now, mostly proprietary glue? Curious... Also, how do you build adaptors so that manual processes are automatically entered in a tracking system? Are you just talking about content management ststems to make it easy to manual reviewers to enter data into ro

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

On Mon, Mar 23, 2009 at 7:22 AM, Gary McGraw 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 > technica

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

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 technical term for the problem is the problem of type safety. C is no

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

On Sat, 21 Mar 2009, ljknews wrote: > The root problem (and I do not care about the terminology) > is that the C programming language promotes the use of > uncounted strings. I'd rephrase that because buffer overflows apply to many other data types besides strings. Anything using an array of po

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

have" ; "Secure Code MailingList" 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 printing, I retooled my F

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

* 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

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

At 11:41 PM -0400 3/20/09, Gary McGraw wrote: > once long ago I spilt a bottle of wine with dan geer > 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 by a local variable on the stack and a gets call) , > it is a bug. Or i

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

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 b

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

> > 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 worl

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

On Fri, 20 Mar 2009, Pravir Chandra wrote: > In fact, I'd be willing to be that for just about every software > security problem we've dealt, I could give you a design/spec level > solution that would prevent it in general (and make auditing and so > forth incredibly streamlined). I don't think

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

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 us