Re: Buffer overflow or overrun?

["Steven M. Christey" <coley () linus mitre org>]

OK, it's been a couple weeks and nobody's answered the question, so
I'll take a stab at it and follow up with some commentary on
vulnerability terminology in general.

Alberto Cozer (acozer () fti com br) asked:

> I've been reading the last Microsoft advisories and one of the
> vulnerabilities descriptions made me think about buffer overrun.
>
> The description for the HTTP header delimiters vulnerability sounds
> like a buffer overflow, although it is described as a buffer
> overrun. And the differences between overflow and overrun are very
> well defined, but it seems that someone is forgetting it.
>
> I might be wrong, but what I understood from the technical description
> is that the problem regards to an overflow. Anyone have any idea on
> that, or knows the reason why it is described like that?

There may be specific differences to some people, but these terms are
often used interchangeably, at least within the context of
vulnerabilities.  More people use the term "buffer overflow,"
approximately 90% based on the Bugtraq archives.

"Buffer overrun" was used extensively in CERT/CC advisories from 1997
and earlier.  CERT/CC probably made a conscious effort to use the
"overflow" term, but I'm not sure.

Sometimes, the same document uses both terms.  For example, a quick
web search brought me to these documents:

  CERT/CC advisory CA-98.10 includes quotes from different
  organizations that use "overflow" or "overrun."

  MS advisory MS00-079 uses both.

  SGI advisory 19980404-01-I uses both, as do other SGI advisories.

  @stake advisory a101200-2 uses both, as do other @stake advisories.

  NetBSD Security Advisory 2001-018 uses both, as do other advisories.

  Red Hat security advisory RHSA-2001:160-09 uses both.

  NGSSoftware "NISR05032002A" has "overrun" in the title and
  "overflow" in the text.  This happens in other NGSSoftware documents
  as well.  The tendency seems to be to use overflow as a verb and
  overrun as a noun.

The usage of "buffer overrun" appears to have declined over the years.
Perhaps someone with more historical perspective can explain why, but
the release of Aleph1's "Smashing the Stack for Fun and Profit" may
have played a part.  There are other entities besides Microsoft and
NGSSoftware who still regularly use "buffer overrun," but none come to
mind.

The terms are interchangeable enough that the CVE search engine
automatically converts "buffer overrun" to "buffer overflow," and CVE
descriptions only use "buffer overflow."  The ISS X-Force and
SecurityFocus databases also use "overflow" extensively, with only a
handful of occurrences of "overrun."

In general, there is a lack of clear terminology throughout the
vulnerability research community.  For example, is it directory
traversal, directory transversal (with an "n"), or reverse directory
traversal, or dot-dot?  To some people, "directory traversal" means
more than just ".." (consider C:file, %2e%2e encodings, or
/absolute/path/here).  And if there's a difference between
authentication and authentification, I can't tell.  "Remotely
exploitable" has a number of different meanings, where some people
mean "over the network without authentication" and others mean "over
the network with authentication" (Scott Blake and Adam Shostack
touched on this at a Black Hat conference a few years ago.)  Just
recently, someone used the term "local" to mean "restricted to the
small network that I own."  People refer to symbolic link
vulnerabilities as a race condition, although there can be other
factors such as directory permissions and insufficiently random file
names.

The most vaguely defined term of all, however, is "vulnerability,"
because everybody has a different definition.  CVE was originally
called "Common Vulnerability Enumeration" until we realized that we
couldn't get everybody to agree on what "vulnerability" really means.
The terminological warfare was serious enough that some people
threatened to withdraw support for the project.  The end result was to
invent the "exposure" term, try to lay out some definitions for the
purposes of CVE *only*, and not force people to actually use those
definitions.

- Steve