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

[ljknews]

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.\
>
>
> 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)

[Andy Steingruebl]

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

[ljknews]

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 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 ).
> Those machines had a fundamentally different architecture
> at the processor level.

Even with Ada (my favorite) it is _possible_ to violate type
safety.  But it requires using a construct for which managers
can trivially scan the source code.  And there are few cases
where it is _impossible_ to program in a type-safe manner.

C++ has an escape from type safety a bit harder to scan for -
dropping into C.

To determine the difference in the effective type safety of
two languages, consider the likelihood that the _average_
programmer is going to violate type safety.  You cannot
manage to hire programmers exclusively from Lake Wobegon*.

Worry about enforcement by the hardware architecture after
you have squeezed out all errors that can be addressed by
software techniques.
-- 
Larry Kilgallen
* For non-US readers, Lake Wobegon is an imaginary
  community where all the school children are above
  average.
___
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)

[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 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 
).  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"  wrote:


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

[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 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  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
> ).  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"  wrote:
>
>
> 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
> 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)

[John Steven]

time as assessors argue with development over semantics, next steps, and 
responsibilities.

Each methodology has its own limitations in this department, resulting from its 
focus and perspective, IMO. If you look at OSSTM, there's a wealth of 
definition around activities, which really helps those implementing it 
differentiate what techniques they could apply in testing their system. Their 
template reporting form falls short on defining constructs such as root cause 
and finding and 'speaks' like an auditor's report. This doesn't do the depth 
and breadth of their assessing techniques justice which means, ultimately, 
adopting it will take a lot of work in the realm of that normalization task we 
treated earlier. NIST's methodology formalized controls even more producing the 
800-53 publication. I need to look at their recent foray into app sec and 
reconsider ASVS much more closely and for much longer to make judgments in this 
realm. Currently, I've only considered it in the insanely and unfairly narrow 
context of "a set of stuff to look for". I'll follow up with you on t!
 his later this week or next.

[Correlating Risk Systems]
Taking your question literally: Risk systems? Most risk management companies 
wield Powerpoint and Excel, and as such, glue is hard to come by--let alone 
'open glue'. I don't have much experience with Archer, but their glue is 
proprietary but their suite includes the ability to weave together policy, 
requirements, findings, and change/bug management. It sits outside the MS 
Office stack, but what little experience I've had with it wasn't necessarily 
positive  ;-)

I hope this answers your questions... if not, fire more away,
-jOHN


From: Jim Manico [...@manico.net]

I like where your head is at - great list.

Regarding:

> Builds adapters 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" 
To: "John Steven" ; ;
"Benjamin Tomhave" ; "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 Free
> Kevin sticker press.
>
> Well stated ;) have a great weekend!
>
> -Original Message-
> From: John Steven 
>
> Date: Fri, 20 Mar 2009 14:35:01
> To: Benjamin Tomhave; Secure Code
> MailingList
> 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

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

[Andy Steingruebl]

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

[Gary McGraw]

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.

Building secure software in a non type safe language is much harder than 
building secure software in a type safe language (like Java or C#).

gem
(still supposedly on vacation in SC)

http://www.cigital.com/~gem


On 3/22/09 2:30 PM, "Steven M. Christey"  wrote:



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 pointer arithmetic is
potentially subject to overflows.  I have little doubt that when you
launch 200 simultaneous connections against a bunch of applications, some
of them will crash because the programmer only allocated enough memory to
store 100 connections at once.  A lot of the IOCTL overflows going on
right now are more about malformed data structures than strings, as are
many of the file format vulns.

- Steve
___
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)

[Steven M. Christey]

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 pointer arithmetic is
potentially subject to overflows.  I have little doubt that when you
launch 200 simultaneous connections against a bunch of applications, some
of them will crash because the programmer only allocated enough memory to
store 100 connections at once.  A lot of the IOCTL overflows going on
right now are more about malformed data structures than strings, as are
many of the file format vulns.

- Steve
___
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)

[Jim Manico]

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" 
To: "John Steven" ; ; 
"Benjamin Tomhave" ; "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 Free 
> Kevin sticker press.
>
> Well stated ;) have a great weekend!
>
> -Original Message-
> From: John Steven 
>
> Date: Fri, 20 Mar 2009 14:35:01
> To: Benjamin Tomhave; Secure Code 
> MailingList
> 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 

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

[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 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)

[ljknews]

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 is it a flaw that the C stack grows in
> an incredibly stupid way?

That reasoning has a bit of not being able to see the forest
for the trees.

The root problem (and I do not care about the terminology)
is that the C programming language promotes the use of
uncounted strings.
-- 
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)

[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 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"  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  chandralistorg
PGP:CE60 0E10 9207 7290 06EB   5107 4032 63FC 338E 16E4
~ ~~ ~~~ ~  ~ ~

-Original Message-
From: "Goertzel, Karen [USA]" 

Date: Fri, 20 Mar 2009 10:06:46
To: Benjamin Tomhave; Secure Code Mailing 
List
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)

[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.
> 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]

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 I disagree, and I've started getting interested in the
design-level choices that make implementation bugs easier to make.
(examples: HTML mixes data/control in the same stream and therefore you
have XSS; OSes mix data/control within programs and thus buffer overflows
in data can execute code; HTTP is stateless and URLs are transportable,
thus you have CSRF; OSes allow the same file object to have multiple
names, thus you have path traversal and symlink attacks; strcpy() and its
ilk don't accept length parameters and are thus easy to abuse, and
besides, C doesn't enforce boundaries for memory accesses; etc.)

Seven Pernicious Kingdoms defined the "API Abuse" category, which I
thought was a recognition of a pretty deep problem.  We've expanded on it
a bit in CWE, although there's lots of room for growth (see CWE-227 and
its children under the CWE-1000 research view).

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.

- Steve
___
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)

[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 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  chandralistorg
PGP:CE60 0E10 9207 7290 06EB   5107 4032 63FC 338E 16E4
~ ~~ ~~~ ~  ~ ~

-Original Message-
From: "Goertzel, Karen [USA]" 

Date: Fri, 20 Mar 2009 10:06:46 
To: Benjamin Tomhave; Secure Code Mailing 
List
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.
___