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 the programming language and the hardware architecture are coupled in terms of the resulting security model. Or they can be anyway. On Wed, Mar 25, 2009 at 8:42 AM, Gary McGraw g...@cigital.com wrote: 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 choice can sometimes make up for bad machine architecture, but ultimately at some level of computational abstraction they come to be the same thing. You may recall that I am a scheme guy. TI made a scheme machine that never caught on some years back (around the same time as the LISP machine...like emacs only even more bindings at least on the Symbolics http://en.wikipedia.org/wiki/Lisp_machine). Those machines had a fundamentally different architecture at the processor level. In any case, type safety is at the root of these decisions and makes a HUGE difference. Go back and read your lambda calculus, think about closure, symbolic representation, continuations, and first class objects and I think you'll see what I mean. http://en.wikipedia.org/wiki/Lambda_calculus gem (supposedly still on vacation, but it is a rainy day) http://www.cigital.com/~gem http://www.cigital.com/%7Egem On 3/24/09 2:50 PM, Andy Steingruebl stein...@gmail.com wrote: 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 technical term for the problem is the problem of type safety. C is not type safe. Really? It isn't that the standard von Neumann architecture doesn't differentiate between data and code? We've gone over this ground before with stack-machines like the Burroughs B5500 series which were not susceptible to buffer overflows that changed control flow because code and data were truly distinct chunks of memory. Sure its a different programming/hardware model, but if you want to fix the root cause you'll have to go deeper than language choice right? You might have other tradeoffs but the core problem here isn't just type safety. Just like in the HTML example. The core problem is that the language/format mixes code and data with no way to differentiate between them. Or is my brain working too slowly today? -- Andy Steingruebl stein...@gmail.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
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 choice can sometimes make up for bad machine architecture, but ultimately at some level of computational abstraction they come to be the same thing. You may recall that I am a scheme guy. TI made a scheme machine that never caught on some years back (around the same time as the LISP machine...like emacs only even more bindings at least on the Symbolics http://en.wikipedia.org/wiki/Lisp_machine). Those machines had a fundamentally different architecture at the processor level. In any case, type safety is at the root of these decisions and makes a HUGE difference. Go back and read your lambda calculus, think about closure, symbolic representation, continuations, and first class objects and I think you'll see what I mean. http://en.wikipedia.org/wiki/Lambda_calculus gem (supposedly still on vacation, but it is a rainy day) http://www.cigital.com/~gem On 3/24/09 2:50 PM, Andy Steingruebl stein...@gmail.com wrote: 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 technical term for the problem is the problem of type safety. C is not type safe. Really? It isn't that the standard von Neumann architecture doesn't differentiate between data and code? We've gone over this ground before with stack-machines like the Burroughs B5500 series which were not susceptible to buffer overflows that changed control flow because code and data were truly distinct chunks of memory. Sure its a different programming/hardware model, but if you want to fix the root cause you'll have to go deeper than language choice right? You might have other tradeoffs but the core problem here isn't just type safety. Just like in the HTML example. The core problem is that the language/format mixes code and data with no way to differentiate between them. Or is my brain working too slowly today? ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)
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 mistakes through things like DEP, ASLR, SEH, etc. why do you think that these can't be done in parallel? I mean, we used to not have Virtual Memory or real MMUs and the developer had to make sure they didn't step on other people's pages. Hardware support for protection on pages has helped with a lot of things right? I'm not saying I'm holding out hope for hardware to solve all our problems (that would be silly) but I do think it can be fairly useful for some classes of problems and a lot more scalable/repeatable. Practical right now, no. But we're sort of in the realm of fantasy in this discussion already if we think the general mass of people writing software are going to switch languages because certain ones are more reliable - Andy ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
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 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, Given the focus we've seen fro Microsoft and protecting developers from mistakes through things like DEP, ASLR, SEH, etc. why do you think that these can't be done in parallel? I don't know any of those acronyms, and I have very little to do with Microsoft. The last software of theirs I bought was Microsoft Word V5.1a, the last one _before_ they introduced Macro viruses. I mean, we used to not have Virtual Memory or real MMUs and the developer had to make sure they didn't step on other people's pages. Hardware support for protection on pages has helped with a lot of things right? Yes, but for me that was prior to 1978, and the benefit of hardware protection pales by comparison to the benefit of not programming everything in assembly language. I'm not saying I'm holding out hope for hardware to solve all our problems (that would be silly) but I do think it can be fairly useful for some classes of problems and a lot more scalable/repeatable. Practical right now, no. But we're sort of in the realm of fantasy in this discussion already if we think the general mass of people writing software are going to switch languages because certain ones are more reliable I don't expect programmers to make that decision - I expect astute management to make that decision (wherever astute management happens to surface). Management has a lot easier time changing languages than changing hardware architectures. Sometimes the hardware is even dictated by the customer (such as when trying to sell into a particular market). -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)
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 technical term for the problem is the problem of type safety. C is not type safe. Really? It isn't that the standard von Neumann architecture doesn't differentiate between data and code? We've gone over this ground before with stack-machines like the Burroughs B5500 series which were not susceptible to buffer overflows that changed control flow because code and data were truly distinct chunks of memory. Sure its a different programming/hardware model, but if you want to fix the root cause you'll have to go deeper than language choice right? You might have other tradeoffs but the core problem here isn't just type safety. Just like in the HTML example. The core problem is that the language/format mixes code and data with no way to differentiate between them. Or is my brain working too slowly today? -- Andy Steingruebl stein...@gmail.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)
Hey John, I like where your head is at - great list. Regarding: Builds adaptors so that bugs are automatically entered in tracking systems Does the industry have: 1) A standard schema for findings, root causes, vulnerabilities, etc, and the inter-relation of these key terms (and others?) 2) Standardized API's for allowing different risk systems 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 rosk mangement software? Anyhow, I like where your head is at and it definately got me thinking. - Jim - Original Message - From: Tom Brennan - OWASP t...@owasp.org To: John Steven jste...@cigital.com; sc-l-boun...@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 printing, I retooled my Free Kevin sticker press. Well stated ;) have a great weekend! -Original Message- From: John Steven jste...@cigital.com Date: Fri, 20 Mar 2009 14:35:01 To: Benjamin Tomhavelist-s...@secureconsulting.net; Secure Code MailingListSC-L@securecoding.org Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) Tom, Ben, All, I thought I'd offer more specifics in an attempt to clarify. I train people here to argue your position Ben: security vulnerabilities don't count unless they affect development. To this end, we've specifically had success with the following approaches: [Integrate Assessment Practices] [What?] Wrap the assessment activities (both tool-based and manual techniques) in a process that: * Normalizes findings under a common reporting vocabulary and demonstrates impact * Include SAST, DAST, scanning, manual, out-sourced, ALL findings producers in this framework * Anchors findings in either a developmental root cause or other software artifact: * Use Case, reqs, design, spec, etc. * Builds adaptors so that bugs are automatically entered in tracking systems * Adaptors should include both tool-based and manual findings * Calculates impact with an agreed-upon mechanism that rates security risk with other factors: * Functional release criteria * Other non-security non-functional requirements [Realistic?] I believe so. Cigital's more junior consultants work on these very tasks, and they don't require an early-adopter to fund or agree to them. There's plenty of tooling out there to help with the adapters and plenty of presentations/papers on risk (http://www.riskanalys.is), normalizing findings ( http://cwe.mitre.org/.) , and assessment methodology (http://www.cigital.com/papers/download/j15bsi.pdf). [Panacea?] No. I've done research and consulting in functional testing. If you think security is powerless against development, try spending a few years in a tester's shoes! Functionality may be king for development and PMs, but I've found that functional testing has little to no power. While a lack of features may prevent software from going out the door, very rarely do I find that functional testing can implement an effective go/no-go gate from their seat in the org. That's why testing efforts seek muscle from their friend Security (and its distant cousins under quality Load and Performance) to stop releases from going out the door. There's no reason NOT to integrate with testing efforts, reporting, and groups: we should. There's every reason security should adhere to the same interface everyone else does with developers (let them produce code and let them consume bugs)... I think the steps I outlined under 'what' bring us closer. I enjoyed Guy's book, but I don't think we need to (or can expect to) flip organizational precedent and behavior on its head to make progress. [Steering] The above scenario doesn't allow explicitly for two key input/outputs from the software security ecosystem: 1. Handling ultra-high-priority issues in real time 2. Adjusting and evolving to changing threat landscapes I've long suggested establishing a steering committee for this. [What?] Establish a steering committee on which a software security, dev, architecture, operations, and corporate risk sit. These folk should manage the risk-model, scoring, security standards that drive the assessment verification standard, and the definition of both short-term and longer-term mitigating strategies. I'd argue that you'd like Industry representation too. That organization could come in written form (like the Top N lists
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 by a local variable on the stack and a gets call) , it is a bug. Or is it a flaw that the C stack grows in an incredibly stupid way? hmm. Necker defect. gem http;//www.cigital.com/~gem On 3/20/09 2:28 PM, Pravir Chandra chan...@list.org wrote: 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 used. Now on to 'bug'... Same thing applies. A missing feature can be called a bug just as well as a flawed line of code (or even a specified feature that does something undesirable). But, I'm of the mind that avoiding security problems in software comes down to specification and design. I know Gary likes to talk about security problems as bugs (code-level) vs flaws (design-level), but this abstraction isn't helpful when trying to build secure software in general (however, it is helpful in convincing people that are bug-chasing to look elsewhere too). 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). p. ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: Goertzel, Karen [USA] goertzel_ka...@bah.com Date: Fri, 20 Mar 2009 10:06:46 To: Benjamin Tomhavelist-s...@secureconsulting.net; Secure Code Mailing ListSC-L@securecoding.org Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
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 world. Based on what I see in CVE, it seems that the answer for item 2 is usually for one component to choose to conform to another's expectations, and that conforming component isn't always the one that should be changed. Those are both definitely apparent at design time. Paraphrasing Bob Blakley, applications are built on composition, but most security protocols are point to point and don't compose. So anyone who bothers to look at the end to end application will see massive gaps in the security protocols. The fix is likely a decision between a sts/federation/proxy pattern, and a way to link policy to mechanism. WS-SecurityPolicy provides one such way to do specify the policy side. -gunnar ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
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 the real world. Based on what I see in CVE, it seems that the answer for item 2 is usually for one component to choose to conform to another's expectations, and that conforming component isn't always the one that should be changed. The really hard things under (2), like the Java/firewall issue, are not fixed at all. Subsequent designs may address it (Silverlight) or not (Flash, post-FTP firewall helpers). The + + + A T H 0 problem is in this cateogry, too. It seems to me that many of those things are, in some sense, layering violations, where one party attaches meaning to properties at a wholly different layer. For instance, the cluster of AS4_PATH issues (which we can't afford not fixing, I think) stems from the fact that BGP has both a message transport layer, and a message semantics layer (much like RFC 821 vs RFC 822). This view is not yet universally shared, though. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
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 used. Now on to 'bug'... Same thing applies. A missing feature can be called a bug just as well as a flawed line of code (or even a specified feature that does something undesirable). But, I'm of the mind that avoiding security problems in software comes down to specification and design. I know Gary likes to talk about security problems as bugs (code-level) vs flaws (design-level), but this abstraction isn't helpful when trying to build secure software in general (however, it is helpful in convincing people that are bug-chasing to look elsewhere too). 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). p. ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: Goertzel, Karen [USA] goertzel_ka...@bah.com Date: Fri, 20 Mar 2009 10:06:46 To: Benjamin Tomhavelist-s...@secureconsulting.net; Secure Code Mailing ListSC-L@securecoding.org Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
