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 Cowan, Ph.D.     
Director of Software Engineering
        AppArmor Chat:

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Reply via email to