[VIM] Crafted vs. malformed: a terminology issue

Steven M. Christey coley at mitre.org
Fri Apr 7 01:43:08 EDT 2006

I like this advisory:


 CSCsc51390: "Control card resets with crafted IP packet."

 CSCsd04168: "Control card resets with crafted IP packet."

 CSCsc54558: "Malformed OSPF packets cause control cards to reset."

So - were the "crafted" IP packets actually well-formed, but just not
expected?  Or was this just a different person writing a different
portion of the advisory who just happened to use a different word?

I've been wrestling with good terminology to distinguish "malformed"
inputs from "well, it's syntactically well-formed but the values
aren't actually correct" from "well, it's all technically allowed by
the specification but dang, we didn't see THAT one coming!"

The issue stems back to the original source, as we see above.  You
don't know what someone means when they refer to "crafted" or
"malformed" or "certain" inputs.  I've tried to make this distinction
in CVE descriptions - if it's syntactically wrong, then it's
"malformed".  If it's syntactically valid, then I use some other
phrasing to say what's wrong with it.  But (a) I still don't have good
terminology and (b) good terminology doesn't matter when your raw
sources are vague :)

I've also been thinking about what Gary McGraw (I think it was him)
and others have referred to as "syntactic" and "semantic" validity.
I'm still a little fuzzy on this, but: if an input is well-formed
(syntactically) but still causes an issue, then maybe it's a semantic
problem.  Then again, if you have a protocol spec that allows a "USER"
command with an arbitrary length username, but an application has a
buffer overflow after 256 characters - then it's syntactically valid
and, effectively, semantically valid.  A Google search led me to a
paper by Alan A. Jorgensen "Testing with Hostile Data Streams" that
also introduces lexical validity, and then "Guns and Butter:Towards
Formal Axioms of Input Validation" which was apparently presented at
Black Hat.

Anybody else think of this stuff when they should be doing REAL work
instead? ;-)

- Steve

More information about the VIM mailing list