Steven M. Christey wrote: > On Mon, 11 Jun 2007, Crispin Cowan wrote: > >> 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. > I thought that the Java 2 security container stuff let you specify file accesses? Similarly, I thought that Microsoft .Net managed code could have an access specification?
AppArmor provides exactly that kind of access specification, but it is an OS feature rather than a high level language, unless you want to view AA policies as high level specifications. >>> 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. > I don't agree with that. I think it is a community gap. The academic security community has a very mature nomenclature for design issues. The hax0r community has a mature nomenclature for implementation issues. That these communities are barely aware of each other's existence, never mind talking to each other, is a problem :) > 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. > Do you suppose it is because of the different techniques researchers use to detect vulnerabilities in source code vs. binary-only code? Or is that a bad assumption because the hax0rs have Microsoft's source code anyway? :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor _______________________________________________ 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. _______________________________________________
