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 _______________________________________________ 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. _______________________________________________
