BSIMM: Confessions of a Software SecurityAlchemist(informIT)

[coley at linus.mitre.org (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