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

[Florian Weimer <[EMAIL PROTECTED]>]

* 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) [EMAIL PROTECTED]
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.
_______________________________________________