discuss terminology: overflow (was Re: [VIM] Zoidcom ..)

[Steven M. Christey]

On Wed, 18 May 2005, security curmudgeon wrote:

> : Multiple sources have referred to this as a buffer overflow, when it's
> : not an "overflow" at least as traditionally regarded.
> :
> : According to Luigi Auriemma's report, the attack involves manipulating a
> : size field of a packet.  This size field, if too big, then causes
> : Zoidcom to "try to read the unallocated memory located after the packet
> : buffer or the library will exit immediately if the amount of bits is so
> : big that the target buffer cannot be allocated."
> :
> : So there's bad buffer management, and modification of length fields is a
> : common attack these days, but in this case, there's no stack-smashing or
> : heap corruption.
> :
> : I'm not sure what term to use, as the underlying bug is still basically
> : the same as the bugs that allow classic overflows, but to just say
> : "buffer overflow" seems inaccurate.
>
> There a VDB dictionary anywhere? I imagine the original term was more
> vague and meant overflowing a buffer. After a while it morphed into the
> more well known overflow (stack smashing etc) but when you think about
> it.. who determines the meaning?

It's informal, near as I can tell, but it seems like VDB's play a strong
role in increasing the adoption of particular terms.

> Another example that just came up with OSVDB. Unspecified vs Nondescript
> .. which is more appropriate?

CVE has been saying "unknown vulnerability" but the trend is clearly to
say "unspecified," and I like that better, so I expect to start using
"unspecified" fairly soon.

> Point being.. has 'overflow' started as one thing, turned into another,
> and now ends up being accurate if the original meaning is applied?

When format string vulnerabilities first came out, they were sometimes
referred to as buffer overflows.  You see a similar thing with integer
overflows and signedness issues these days.

I think that "overflow" first started as - "blindly copies a large input
buffer into a smaller input buffer," but now there are a whole lot of
variants to that.  Consider cases where there are 2 inputs - a length
field and a string - and the application trusts the length field but
doesn't verify that the provided string is that length.  That leads to an
overflow, but it's more than a "blind copy" error.  Or take off-by-one
overflows, which are really due to a mathematical bug.  It used to be that
you just provided a single large string of 'A' characters - now, multiple
strings are constructed, and the overflow may arise because the
application doesn't properly track "special" characters.  Or you use
special characters that wind up being expanded in the final string, e.g.
"&" might become "&" in a web app.

>From the programming side, you're seeing a lot of different bugs cropping
up; the exploits, at their core, are the same (provide more input than
allocated), but with these new bug types, the exploits may require more
"prep work" and/or multiple inputs, where a "classic" overflow was just
one input, one bug.

> case there is a small buffer being provided too much information, and
> the program acting poorly. Isn't that "overflowing" the buffer?

The problem is that "overflow" once merged both programming bug ("blind
unbounded copy") and attack technique ("send larger string than
expected"), but now there are multiple bugs and multiple attack techniques
all being described with the same term.

- Steve