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 (acozerat_private) 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
This archive was generated by hypermail 2b30 : Sun Apr 28 2002 - 21:46:10 PDT