Harvard vs. von Neumann

[coley at linus.mitre.org (Steven M. Christey)]

On Mon, 11 Jun 2007, Crispin Cowan wrote:

> Gary McGraw wrote:
> > Though I don't quite understand computer science theory in the same way that Crispin does, I do think it is worth 
> > pointing out that there are two major kinds of security defects in software: bugs at the implementation level, and 
> > flaws at the design/spec level.  I think Crispin is driving at that point.
> Kind of. I'm saying that "specification" and "implementation" are
> relative to each other: at one level, a spec can say "put an iterative
> loop here" and implementation of a bunch of x86 instructions.

I agree with this notion.  They can overlap at what I call "design
limitations": strcpy() being overflowable (and C itself being
overflowable) is a design limitation that enables programmers to make
implementation errors.  I suspect I'm just rephrasing a tautology, but
I've theorized that all implementation errors require at least one design
limitation.  No high-level language that I know of has a built-in
mechanism for implicitly containing files to a limited directory (barring
chroot-style jails), which is a design limitation that enables a wide
variety of directory traversal attacks.

If you have a standard authentication algorithm with a required step that
ensures integrity, then a product that doesn't perform this step has an
implementation bug at the algorithm's level - but if the developers didn't
even bother putting this requirement into the design, then at the product
level, it's a design problem.  Or something like that.

> > If we assumed perfection at the implementation level (through better
> > languages, say), then we would end up solving roughly 50% of the
> > software security problem.
> The 50% being rather squishy, but yes this is true. Its only vaguely
> what I was talking about, really, but it is true.

For whatever it's worth, I think I agree with this, with the caveat that I
don't think we collectively have a solid understanding of design issues,
so the 50% guess is quite "squishy."  For example, the terminology for
implementation issues is much more mature than terminology for design
issues.

One sort-of side note: in our "vulnerability type distributions" paper
[1], which we've updated to include all of 2006, I mention how major Open
vs. Closed source vendor advisories have different types of
vulnerabilities in their top 10 (see table 4 analysis in the paper).
While this discrepancy could be due to researcher/tool bias, it's probably
also at least partially due to development practices or language/IDE
design.  Might be interesting for someone to pursue *why* such differences
occur.

- Steve

[1] http://cwe.mitre.org/documents/vuln-trends/index.html